Re: Life beyond CGI and DBI

[tilly]

I'm sorry to have to be blunt here.

If I was interviewing someone for a potential job and he or she had been writing CGI applications for 5 years without seriously investigating what resources were available to do things better, then I would recommend against hiring. Here is why:

1. That person will be unfamiliar with every module that is at my workplace. That would be a long learning curve.
2. That learning curve is likely to be slow - you need to learn how to pick up and evaluate new modules. If you haven't learned, then you are unlikely to be familiar with the necessary techniques when you first encounter them.
3. I would automatically distrust his or her design sense. The heart of good design is a tendency to question whether problems that come up could be solved in a better way, and searching for what that might be. This is not consistent with sinking into a rut and staying there for 5 years.
4. I would be inclined towards distrusting his or her skill level. There is a difference between 5 years of experience, and one year of experience repeated 5 times. This sounds like the latter happened.

Furthermore if the roles were reversed and I was the one interviewing for the job, huge red flags would go off for me, and I would be strongly inclined against working there. Mainly because of what it says about the work environment and my likely interactions with co-workers there. Having to deal with the consequences of what I know are basic mistakes repeated over and over again is painful. Giving a remedial education to people who think that they don't need it is hardly my idea of fun either. That goes double if they are smug about their lackings, and/or have support from management.

Sorry, but this is my reaction. Whether or not you care about it is your decision.

If you do care, then a few places to start are by looking into source control systems, playing around with Class::DBI, or searching for templating systems. Or you could read a book, either Perl-specific (O'Reilly has a pretty good library, add in TheConway's OO Perl if you want), or more general (Code Complete is a good start).

Oh, and as pointed out by Abigail-II, start calling the language Perl.

[Anonymous Monk]

If I was interviewing someone for a potential job and he or she had been writing CGI applications for 5 years without seriously investigating what resources were available to do things better, then I would recommend against hiring.

And if I was interviewing someone for a job and they posted this I wouldn't hire them either, but that's not the slightest bit relevant now is it?

punchcard_don is not asking "would you hire me based on this post" he's asking for recommendations on whether other areas of Perl programming are worth learning¹. Saying "I'm wouldn't hire you cause you suck nananananana"² in response doesn't really add anything to the discussion.

In addition, he says he's been "working with Perl for 5 years now." That doesn't mean it's been his full time employment, it doesn't mean he claims to be an expert, it doesn't mean anything more than he wrote.

Either way, he's asking for advice and trying to learn. Your reply definately won't assist him in that area. I expected better.

¹Before it's pointed out. Yes, everything is worth learning, but currently time is finite so you have to prioritize.

²Not a direct quote.

[tilly]

Out of order points of reply.
• My presumption that he had been doing Perl for work is based on his phrase, ...but work has never brought me to these places.
• His phrasing, ...am I an accidental wise-man...is some of this other stuff marginal and/or just for elegance? strongly suggested to me that he is looking to validate his continued non-investment in self-education. I therefore wanted to write a reply that he couldn't possibly misinterpret. Yes, I am reading between the lines there. I know that my habit of trying to read between the lines sometimes gets me into serious unnecessary trouble. But I believe that the times I hit on something important that would otherwise have been missed pay for the occasional debacle.
• I think that it is relevant that you independently would have decided based on the above information to not hire. That demonstrates that my opinion is not exactly an isolated one. I think that it is nicer to honestly tell people who ask where they can improve than to be silent and let them be confused later about why they are being rejected.
• I thought that it was worthwhile to add to this thread a short discussion of some of the things that people (both the original poster and other bystanders) should look to get out of their own learning efforts.
• The only set of expectations that I try to satisfy are my own. I long ago accepted that trying to meet other people's expectations is a losing game which I won't worry about. OK, I'm not as extreme as Linus, but I certainly understand where he is coming from...

[Anonymous Monk]

Fair enough (yep, that's my entire response ;-)

Thanks for the link, I hadn't read that before. I'll leave the discussion of whether or not that's a good example of project leadership for another day :)