I’ll get right to it: Is it the experienced programmer who knows exactly how everyone should be programming perl or the less experienced programmer who is willing to adapt their programming style to the existing practices of the company?
There is no easier answer.
On the one hand, the experienced programmer will bring the quality of work up at the company. However, depending on their personality, they may insist on re-writing chunks of code that might be less than textbook perfect but working perfectly well. And, as we know, every re-write means more testing. Not only that, but it doesn’t do the existing programmers morale much good when the new more experienced guy comes in and starts bashing their code as outmoded and difficult to work with.
But is the inexperienced programmer much better for the company? They are going to make mistakes. Their code will need more scrutiny by others and therefore be more costly to the company. And that means less take home for everyone. Sure, the existing programmers will enjoy the fact that they are still leaders in the organization, but is an ego-boost really worth the cost of training the programmer?
This one’s like economics. “on the one hand, but on the other, ” what in heck is Bernanke talking about anyway?
For me, it boils down to temperment. If you’re experienced and cocky – forget it. But, if you’re a team player and willing to deal with some “inferior” code while you help the team up its game – then you’re in.
If that’s you, check out our job posting at http://jobs.perl.org/job/14908 (only central Fl candidates need apply)
Hey and let’s not forget the inexperienced guys out there. Do you want to be a perl rockstar? Are you willing to put in the hours to learn what you don’t know? Are you willing to do a lot of support calls in order to really learn the application. If that is you, then you should check out our job posting too!
http://jobs.perl.org/job/14908 (only central Fl candidates need apply)