Communication is almost a key in landing a good job. Being able to express what you mean in clear language that non-technical people can understand is vital!

Understanding and solving people's problems is also very important. Often a customer will ask you to do something, but they aren't telling you what they mean, only what they think you need to know. You need to be able to ask a lot of questions, even questions you might take for granted. If you can give a customer what he really wants then you're on your way to making it!

Lastly, I can say I am a Perl Developer, and have been contracting in this mode for the last year-and-a-half. Previous to that I was in a non-software-development role but had been creating systems in Perl for others as a natural part of improving processes in another company.

Perl roles are thin on the ground, this much is true. There isn't the prolific listing Perl roles as there is of C++ or dot-Net or Java. You need to be flexible about where you live.

Some companies have moved towards Perl-based development, and these companies cannot get enough good Perl programmers. Often I have been asked in a role if I know anyone else that is good - and I have to say no as I know few good Perl programmers personally.

Companies that look for Perl programmers rarely look for code-monkeys, like other language based roles may require. A company that moves towards a Perl environment often is looking for a pragmatic developer that is as valuable in design and creativity as they are technically.

Which brings me back to the start of this article. You must develop your communication and creative skills if you want to succeed in Perl development roles, by-and-large. Good luck!

Some companies have moved towards Perl-based development, and these companies cannot get enough good Perl programmers. Often I have been asked in a role if I know anyone else that is good - and I have to say no as I know few good Perl programmers personally.

My current employer is having this problem actually. They are looking to hire two perl developers, but the -two- candidates thus far have had minimal perl experience. And my last employer complained that while it is easy to find perl scripters it is difficult to find perl software engineers.

My advice to the OP is to work on placing yourself firmly in the perl software engineer role, which shouldn't be difficult given your background in C++. You may have trouble getting started if you don't have much professional perl experience.. but that could be helped by side projects. Here are a few things you could do to make yourself more attractive:

1. Contribute useful modules to CPAN (but check for existing functionality first)
2. Submit patches to CPAN modules
3. Create test cases for CPAN modules that you frequently use, when you find an edge case that isn't tested
4. Participate on perlmonks. I have learned more from answering questions and being corrected than I have from most books
It would also be helpful to read the following if you are serious about pursuing perl in your career:
• Higher Order Perl
• Perl Best Practices
• Object Oriented Perl
• Perl Testing: A Developer's Notebook
• Perl Hacks
But perhaps most importantly you should consider what area of perl you want to work with, and build up the related skill sets. For example if you want to work on web applications you should spend a lot of time learning different databases and templating systems.

Perrin, you are both very good and are known to be very good. The job market for you is unlikely to be similar to what it is for a relatively new Perl programmer. Particularly since lots of shops want to hire senior people if they can.

Fair enough, but my point is that there are jobs and that many of them come across the Perl Jobs mailing list every day. There was an actual hiring slump for a year or two, but it seems to be behind us.

I was in high school during the .com boom, so I can't compare the state then to now, but I can confirm getting a fair amount of recuriter calls. I suppose I'm experianced enough, but certainly not as well known as Perrin.

Of course, breaking into a Perl career will be difficult for someone with only a little Perl experiance. Perl must be programmed well or it just becomes a mess, so experianced Perl developers aren't just nice to have, but actually essential if you want to do Perl development at all.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Markets are mindless; they no more understand Perl than weather understands birds (i.e., "markets" are just an environment in which Perl programmers try to find work.).

Programmers -- especially beginning programmers -- frequently conflate a language (Perl, Java, COBOL, INTERCAL) with programming. This is a mistake: programming languages are tools for programmers; they are not programming, in the same way that T-squares, pencils, and triangles (and ducks and splines) were tools for designers, but aren't design. Designing good programs is difficult (NP-hard 8-)). It may be easier to code them in Perl than in Ook, but the design skills are quite a lot harder to learn than a new language. Concentrate on those.

Employers (at least US employers) do tend to look for specific skill sets, mostly because the corporate culture of treating skilled employees as disposable has caused most sensible people to treat employers in the same way. Conversely, employees have to fit into a working environment. See, for example Skud Robert's geek ettiquette site.

There are also many important programming issues that have absolutely nothing to do with the language used for coding:

• Documentation. Bad documentation (my current bête noire is one of the commercial installation building programs) can make using a program painful. Documentation includes that for end users (customers, those people from whom the money for your paycheck comes) and that for maintenance programmers (I've dealt with code that originated in the mid 1950's).
• Specifications. This is what your customers want; it's a programmer's responsibility to make sure s?he understands their needs and that their needs are realizable.
• Team work. Most large programs are not created by an eremitic monk with a laptop and a brilliant idea. Maybe that's how Knuth came up with TeX and Larry Wall created Perl, but it sure is not how quite a few other programs came to be. See, for example, NASTRAN, and CCSM

Incidentally, your title can be read to be "the market is stupid because it understands Perl." You may have meant "Market is too stupid to understand Perl."

Please all you Perl Gurus, how do you make a living and let you career graph improve with Perl.

Honestly, only once in my 20+ year IT career has Perl been the sole focus of my profession. Perl is more apt to be used by me as a tool. As a Unix Engineer I use Perl for all sorts of things. Data scrubbing, data manipulation, data gaterhing, monitor scripts, intrusion detection, virus activity detection, reporting etc. etc and the list goes on. You get the idea.

Even using Perl as a tool and not the sole source of my income I find myself constantly on a search to "do it better" as any true professional should.

My maternal grandfather was a brick layer. Well konwn by other tradesman as being a master craftsman of the highest order in all phases of masonry. Considering in his day tradesmen in the building and other associated industries were a steely eyed lot who were not impressed easiliy this was high praise from his peers,

In spite of his having "made it" in his chosen profession Grandpa was constanly honing his skills, trying different techniques, innovating new methods and generally improving himself as he went along. Again, in my mind this is what seperates the true craftsman from the guy who just does it for a living.

Any profession that you take pride in what you are doing this is true. You constantly want to upgrade your skills. For me that means constantly writing in code. The language doesn't matter, it's that I'm writing.

You mention Java, Struts, (you didn't mention Tiles). I'd say step back and go one further if you are going to go down that road. Look at the entire JSP/Servlet/J2EE world and learn all you can. Install a Tomcat or Cocoon product on a machine you can safely tinker and and write some simple apps and just go from there.

Just as an aside I did that very recently myself. I ended up learning Weblogic, JSP and Servlets out of self defense. One of the developers I was supporting in my Solaris role kept insisting the reason his application kept crashing was due to a misconfigured Solaris environment. Over time I was able to prove to everyone's satisfaction (except his) that the JSP code was rotten.

So while Perl is my favorite environment to program in, I sill don't hesitate to move out of my comfort zone and learn new things. Hell, I even use Perl sometimes to assist in my Java development tasks. But that's a future CUFP. :-)

I had a manager once tell me that after you reach age 40 you shouldn't bother leaning anything new. I voiced the opinion to him that that's true if you want to be seen by your peers, subordinates and higher ups as a dinosaur. If you stop learning, as far as I'm concerned, you're dead.

I've been lucky enough to have worked for companies where my habit of going off on a tangent and playing with stuff totally unrelated to my job spec is tolerated. I've gotten pretty good at taking my new toys and turning them into new products / services for the company, so when I'm off the beaten track poking stuff with a stick to see what it does, I get left alone long enough to see if any results are forthcoming. I therefore subscribe to the school of thought that says that it is, to a degree, up to the employee to prove benefit for a particular tool. If you can, the company you work for may just be happy enough to leave you to your new bag of tricks, so long as there are tangible results for the company in return. Win win? I like to think so. But maybe my bosses simply humour me until such time that they can find a monkey willing to work for fewer nuts ;)

You might consider learning English, too. It's a more valuable skill than Perl, in general.

There's no need to be rude about it.

That said, you do have a point. Being an effective member of a team requires effective communication, and investing some of your efforts in improving your communication skills will do a lot for your career.

The original poster's skill with English is enough to get the point across.. but in business that is not enough. You need to be able to sell yourself, and to express your ideas in a way that convinces others. Perhaps a course on technical writing would help.

It's one of the things on my personal todo list.