Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

What is a Junior Perl Programmer?

by princepawn (Parson)
on Nov 20, 2000 at 04:27 UTC ( [id://42449]=perlquestion: print w/replies, xml ) Need Help??

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.

Replies are listed 'Best First'.
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

      "(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.
        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

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

      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}
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

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.

Re: What is a Junior Perl Programmer?
by extremely (Priest) on Nov 20, 2000 at 09:55 UTC
    In my experience, a Junior Programmer isn't responsible for higher level abstraction. In a larger programming environment the junior programmers are given individual components and the senior programmers are expected to stitch the parts together and work on the core api and coding. What all that means to individual Perl programmers is up to you. In my opinion, there are people who can kick out good code but can't be trusted or expected to design complete systems. Call it experience or ability, some people aren't able to put together larger, complex code systems but can write a perfectly good script or module. Senior vs. Junior is more about design ability than coding ability.

    --
    $you = new YOU;
    honk() if $you->love(perl)

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
      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"

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://42449]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (5)
As of 2024-03-29 01:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found