princepawn has asked for the wisdom of the Perl Monks concerning the following question:
I have often noticed HR terms such as junior and senior-level programmer. Is the difference that they both know the language completely but one has more experience?
Or would you say that the difference is that one understand all parts of Perl but object-orientation?
My feeling is that there really can't be anything such thing as a Junior programmer in Perl. Any such individual is safer called a "Cargo-cult programmer" or "cut-and-paste-programmer" and by-and-large you spend more time fixing their code than you would if you just wrote the code from scratch.
Also, I think there is a serious difference between a software developer and a software designer. To date, due to the nature of the job market, I have been forced to be both designer and programmer.
I have bought a few books on Design Patterns and OO Modeling, but I really never feel comfortable with the software architectures I create.
Currently, I am working for a dot-com which has hired out a major software architecture design firm to actually build the site. This is cool because they already have a framework for the Perl code I have to write --- I just have to write it.
Re: What is a Junior Perl Programmer?
by Trimbach (Curate) on Nov 20, 2000 at 10:15 UTC
|
One of my (many) hats, believe it or not, is HR Specialist for the Federal government. All of the posts above gave good answers, but I'd like to add that the biggest difference between "junior" and "senior" in HR speak is not what you can do, but rather what you are paid to do.
Most work projects can be divided into three kinds of work: easy, moderately complex, and very complex. In terms of the amount of work in each category there's a little work in the easy category (someone has to do the photocopying, for example) and some of the work is in the "very complex" category, but the majority of the work usually falls in the middle ground. Given this scenario the most cost-efficient way to do business is to hire a few, skilled, highly paid individuals to do the "very complex" stuff; a few unskilled, low paid individuals doing the "easy" stuff; and everyone else stuck in the middle. This way you don't have to pay for skills that you don't need, and you keep your salary costs down.
Now this doesn't say anything about what all those shmucks (the "junior" types) doing the "moderate" work are actually capable of doing. They might all be freakin' geniuses with 200 IQ's... but a company could care less. They only need (for example) a couple of skilled folks in the high skilled jobs, and so long as everyone else does what they're supposed to, all is well.
Now, just because a company isn't willing to pay a highly skilled person in a moderately skilled job a high amount of money doesn't mean that company won't take advantage of the situation if it presents itself. Smart people are good to have in a company... they take initiative, they go beyond their job description, they add to the company in lots of ways. Companies love these employees, because they're getting unexpected perks from these guys without having to pay for it. In this respect Merlyn's joke wasn't really a joke at all: "A junior programmer is just a programmer who expects less pay, because they don't have the budget for a real programmer." But I would add, if the SuperGenius Junior programmer leaves, they're easier to replace because although a company would love to pay a SuperGenius Junior-level pay, they really don't need a SuperGenius so they can live without it if they have to.
The big downside here is that it is entirely possible for a SuperGenius Junior to work for a less-talented, less-skilled, (but higher paid) superior. Again, from a company's perspective this is generally ok, so long as the senior employee does the work the company expects, and the junior employee does what he is expected to do. Now, if the company was smart, they'd find a way to boot the senior and replace him with the junior, but this doesn't always work out that way for lots of different reasons (seniority, commitment to employees, non-programming skills, etc. all play into this kind of decision.)
Gary Blackburn
Trained Killer | [reply] [Watch: Dir/Any] |
|
"(many) hats...HR Specialist for the Federal government... Trained Killer"
Wow. Is this even remotely representative of the broad range of duties that the average government worker exercises? Are there people who carry the duties of both social worker and drill sergeant? Could that mild mannered library janitor also be a Navy Seal?
On the other hand, this does answer quite a few questions about the employees of the postal service...
And no, I don't own 27 pairs of sweatpants.
| [reply] [Watch: Dir/Any] |
|
Heh heh heh... very funny. I can say that the "HR Specialist/ Trained Killer" designation DOES make it easier to fire people. ;-D
Once again, though, you've said something very, very true. Although I personally am not entitled to it, the various types of hiring preference extended to veterans of the armed forces guarantees that there will be TONS of feds out there who were "drill sergeants" and "Navy SEALs" and lots of other things. (Many including jobs that can be best described as "uses guns really well.")
And yeah, it also (and I'm serious here) explains the Postal Service, because the Postal Service (must) hire even more vets than normal because of the unskilled nature of the work.
I'm not suggesting that Vets are more or less likely than the average person to go whacko... I'm just saying that when they do they have the potential of going whacko in a much more spectacular way, and since the Federal government is rife with vets... well... there you go.
Gary Blackburn
Trained Killer
| [reply] [Watch: Dir/Any] |
Re: What is a Junior Perl Programmer?
by merlyn (Sage) on Nov 20, 2000 at 04:35 UTC
|
A junior programmer is just a programmer who expects less pay, because they don't have the budget for a real programmer. AKA "hungry".
{grin}
-- Randal L. Schwartz, Perl hacker | [reply] [Watch: Dir/Any] |
|
To be fair, I think that for less pay, you generally would at least get a few more "play dumb" cards to trade in at your disposal :).
:|BastardOperator|:
{From Hell}
| [reply] [Watch: Dir/Any] |
Re: What is a Junior Perl Programmer?
by maverick (Curate) on Nov 20, 2000 at 07:18 UTC
|
Business aspects are not my forte, so I'll just explain how I
see the connotations. :)
When I hear the term Junior (foo) I tend to think of someone
who is going to be working as part of a team, but not in a
leadership type position. ie. a person who is just following
the specification that was given to him/her by someone else.
I tend to think of it in terms or titile/position as opposed
to skill level. In this case, the position dictates that they
aren't making decisions, just following orders.
The Senior (foo) on the other hand, is the person who has a
hand in the decision making process of the tasks. They then
pass off part or all of the grunt work to the Juniors.
Of course, this scenario could be adjusted depending upon the
size of the organization. Maybe you have Seniors, Juniors, and
grunts. The Seniors make the big decisions, the Juniors decisions
over implementation details, and the grunts just follow orders.
I think that there are those who may be excellently knowledgeable
within every aspect of a language, but can't make design type
decisions. And there are those whoe can make excellent designs
but aren't guru's within programming. And of course, there are those
who are pretty good at both. It could also be seen as a case where
it's what you prefer to do as job and not stictly a matter of capabilty.
Since HR has to have a label for the job position, following
command heirarchy for labels is perfectly valid, and isn't really a
perfect parallel to a person's skill.
/\/\averick | [reply] [Watch: Dir/Any] |
Re: What is a Junior Perl Programmer?
by turnstep (Parson) on Nov 20, 2000 at 07:16 UTC
|
Sometimes it is a just a matter of "title" and management speak.
If they have 5 perl programmers, one must be "senior" and the rest
"junior." In some places, this means the "seniors" are actual team
leaders and have pseudo-management jobs regarding the other
programmers. In other places, the job is the same, but the
"senior" ones get paid a bit more. For others, a set amount
of experience equates to one level or the other. I have found
that years of experience does not equate so easily to the actual
ability to excel at a project and write good, clean, efficient
code. At least not as much as other careers. In general, as
stated above, avoid "junior" designations like the plague. Push
for senior, even if you don't feel worthy of the title yet.
When it all comes down to it, it's just a title. There are
programmers out there straight out of college who have passion
about a language (e.g. perl) and who can code circles around
"experienced" programmers who are comfortably competent.
| [reply] [Watch: Dir/Any] |
Re: What is a Junior Perl Programmer?
by extremely (Priest) on Nov 20, 2000 at 09:55 UTC
|
| [reply] [Watch: Dir/Any] |
Re: What is a Junior Perl Programmer?
by mrmick (Curate) on Nov 20, 2000 at 18:51 UTC
|
I think this tends to be more representative of the
complexity or, rather, the scope of the role.
A junior programmer, whether he be highly skilled or
not, tends to interact mostly (if not always) with the
members of the team to which he belongs.
A senior programmer would have a much broader scope in who
he deals with because he is the one who is actually
communicating with the customer or the end user(s) or other
departments if in a large corporation. He's the one who
takes a leadership role with his team members has to put up
with all the political crap from everyone else.
Mick | [reply] [Watch: Dir/Any] |
|
Job titles are always a touchy thing. I have been at my
present job for over 10 years, and my title has evolved
over the years. The general outlines of my job have not
changed much, however. I have always been a database
administrator and unix system administrator doing work that
has increased steadily in complexity.
My title has not always reflected what I do because of
some anal-retentiveness of Human Resources and the central
IT department. HR didn't want to allow my supervisor to
pay me much more than what I was getting, and IT wanted
strict control over job titles. Finally I made a lateral
move from Research Specialist to Scientific Programmer/Analyst
and moved into the Senior Scientific Programmer/Analyst
title aver a couple years. While this sounded high-falutin',
it still did not reflect how I spent most of my time.
Then about a year ago, HR finished a study of pay equity and
title issues for IT job classifications, and decided that we
would all change to titles that were pretty standard across
the country (so they said), and that our pay scales would
shift a little closer to similar types of workplaces in
other places. Each title would have steps within it (entry,
specialist, expert) which could be traversed without filing
a whole new job classification form.
The upshot is that all the various programmer/analyst
titles were folded into one -- "Programmer/Analyst" -- with
steps within the title for pay. An entry level PA could
simply refer to oneself as a PA, thus shedding the stigma
of being the lowest level.
I was able to move into the Database Administrator title,
get a pay raise, and have plenty of room to advance in pay.
At our site, nearly all of us with new titles know and
use Perl as an adjunct to our duties. (how's that for
slipping back on topic?...)
-----
"Computeri non cogitant, ergo non sunt"
| [reply] [Watch: Dir/Any] |
|
|