Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Perl Test

by Faoahy (Novice)
on Oct 22, 2009 at 07:53 UTC ( #802677=perlmeditation: print w/replies, xml ) Need Help??

I decided to post this question here since this section is for discussions of non-programming related issues. But to tell you the truth, I really dont know if this is the right place to post this question but here it goes.

I was tasked by my superior to check the knowledge level of our developers on Perl. Previously, the developers were asked to learn Perl by self-study. Time was the only thing provided (no training). After 3 months, the developers are saying that they have learned a lot and have used it on their work. But we dont have any idea on how to gauge their knowledge gained.

Will you guys suggest on how to do this? how to gauge/check their knowledge so that we can have an idea which of our developers has potential or whom needs more training or time to learn.

We noticed that they are using perl on their work and most of their scripts are working. But how are we going to know if what they did is the best practice or the best way to do that. Note that we dont have a senior level or an experience developer to check their code.

Any suggestion, comments are welcome. And if you think that this question is not for this section, you can remove it but please tell me the section where I should post this.

Thanks in advance!

Replies are listed 'Best First'.
Re: Perl Test
by jakobi (Pilgrim) on Oct 22, 2009 at 08:27 UTC
    No replies here, just some more ideas to consider:

    • better make the test something directly useful to the developers themselves, something they can use to improve themselves with, rather than a mere gauge.
    • pair programming or peer review between your developers, e.g. selected non-trivial scripts. And improve code quality & skills faster, thus resulting in less debugging time in the long run. With an requires an explicit decision from management to support this kind of investment of time.
    • having some senior architect or lead would be helpful. Or consider asking each developer to dedicate some extra time for testing & coding in order to become the senior/expert for a certain category of modules or usage scenario. Maybe ask them for (short mini) talks about their areas of expertise + maintained resources & handouts in a wiki.
    • check the coders at work thread for more ideas: Questions from "Coders at Work"
Re: Perl Test
by Ratazong (Monsignor) on Oct 22, 2009 at 10:01 UTC
    We had an similar issue long ago when starting Java.
    • in my experiences, the best is doing code-reviews, with constantly changing teams of 5-6 developers - that way the author and the reviewer learn something
    • you can also let the developers create a code-review-checklist and a perl coding guideline/best-practices - this forces them to look even deeper at the language
    • and to reflect on the way they code
    • as others said, involving an (external) expert to support that is helpful
    HTH, Rata
Re: Perl Test
by GrandFather (Sage) on Oct 22, 2009 at 08:21 UTC

    One way you could get some idea of where they are at would be to post a little of their code here (with identifying material appropriately expunged of course). The first 30 or so code lines of a couple of source files are likely to give us a pretty good idea of what they are doing.

    True laziness is hard work
Re: Perl Test
by JavaFan (Canon) on Oct 22, 2009 at 09:14 UTC
    Note that we dont have a senior level or an experience developer to check their code.
    Then you have no way of knowing what they are doing. Even if you have a test that perfectly gauge their knowledge, if you don't inspect the code, you don't know how they used the knowledge. Note also that knowledge of a language doesn't imply a "good coding style", nor is it a requirement.
Re: Perl Test
by toolic (Bishop) on Oct 22, 2009 at 12:57 UTC
    But how are we going to know if what they did is the best practice or the best way to do that. Note that we dont have a senior level or an experience developer to check their code.
    You could automate the process using Perl::Critic, which can be customized to highlight what you deem important.

    Another effective method for checking code robustness is to run the code on the various platforms/OS's and versions of Perl you have available to you. For example, here @work, I have 3 versions of Perl (5.8.5/5.8.8/5.10.0) installed on 2 linux variants (32-bit/64-bit).

    Perl::Tidy is another handy tool to guide new users on consistent code layout practices.

      Perl::Critic is a great measure of code quality, but not programming skill, or knowledge.

      If a company is not willing to invest in its employees or skilled programmers to evaluate their work, I imagine they are not going to learn much in the short-term.

      It is like you and your friends trying to learn a foreign language from a book. You will not learn it very well until you get someone who already speaks it.

Re: Perl Test
by raisputin (Scribe) on Oct 22, 2009 at 23:38 UTC
    I really don't have any useful ideas on how to gauge this for you other than what has already been mentioned. But it is, to me, an interesting question because here at my job, I am in that exact situation
    • Using perl extensively
    • no budget for training, so learning on my own
    Here is what I can tell you about my own programming. I start out doing every single program in a way that I understand.

    From there, I go back and look at what areas I think can be improved on and why. Most of the time, there is probably a "better" way to do it. I look around on here and the internet in general and see what I can find that may or may not help me create better code.

    Sometimes, a search reveals a solution that is better than my own and that I understand, so I use it. For me, understanding why I am doing something and how it works is far more important than having code that is "the best solution". If I don't understand how the code works, I generally bookmark it for later and move on with my own code. Other times, I find no other solution that will do what I need even though one may exist, and probably does. Sometimes, I post here about a problem and get an answer that I understand, so I use it.

    I try to break down what I am doing into small easy to understand chunks that can be modified without breaking too much, and that seems to be key for me. Taking it in little bites when I can, and getting it all working.

    My current project is an internal perl module to interface with our Cable Modem system. My previous solution worked fine, but ended up being a few thousand lines of code too many and with a lot of convoluted routines that I have since looked at and went "!@@!@!!!!! WTF did I do that for!@@$@#!!!!". So now I am rebuilding that entire thing as a module which will be reusable in many different applications that I am building that all interface with the Cable Modem System.

    Fortunately I don't have any strict timeline, so I am able to spend a lot of time working through problems. My most recent was a Hash of Arrays.

    So as for your question, if there is nobody that has a higher level of knowledge than the developers, you are kinda in a tough spot. If you care about the apps working more than best practices, I would say let them continue on their way, learning as they go. They will eventually look back and go "Why did I do that?" and then fix it up :)

    Just my $.02. I haven't been developing in perl for very long either at least not in a meaningful way as far as I am concerned. So take it for what you will.

Re: Perl Test
by ack (Deacon) on Oct 30, 2009 at 17:29 UTC

    This is most interesting posting and I have enjoyed both the op's post and all of the responses. Some of the response have tried to do what I would call "making the best of an unfortunate or bad situation" while others have offered good, "how it *should* be done" responses. For me, the crux of the difference between those two approaches is, indeed, the availability, or un-availability, of "experts".

    I don't have any specific advice, per se, beyond all of the good responses that have already been offered. But I *do* some some experience that I'll share (if the readership can indulge my writing).

    We use Perl at work as the centerpiece of our systems integration & testing efforts and also, to a somewhat lessor extent, for actually operating (or automating our operating) of the systems.

    However, we only have a few folks (maybe 2 or 3) who would be really considered "seasoned" Perl programmers. They are rarely available to help beginners and generally have not learned or used any more Perl than is the bare minimum to "get by". So even they have no real depth or appreciation of Perl beyond the basics. They are, however, excellent, creative and seasoned programmers so they can make even the basic structures and strategies "sing" in very complex situations. They were essentially not available to help me; so my situation is not too unlike the general situation of the OP.

    As the most Senior Chief Systems Engineer, I continually felt like I would be so much more useful and helpful if I understood and used Perl, too. So I undertook to learn it...on my own.

    I very quickly realized how very much I wanted, needed, and could benefit from having an "expert" Perl programmer available to answer all sorts of questions that nagged me. Instead, I had hunt the answers down myself.

    That was, on the one hand, very valuable as it taught me a lot about the resources that were available and opened up an entire world of expertise that has proven again and again to be "my friend." It also led me to the Monestary; which provided incredible leverage to my learning and has taught me so very much about how to be a good Perl programmer (I have done programming professionally in other languages for several decades); but learning how to tap into the strenths of Perl and how to apply it efficiently and most productively is almost impossible to learn on one's own; hence the Moneastary has transformed me most incredibly as a Perl programmer.

    But it also took way, way longer to learn even the basics than it should have. In retrospect, it took me about 3 years of trial-and-error, hunting for answers on my own, and doing many, many coding projects before I began to feel "competent" as a Perl programmer. In retrospect (and comparing my experience with previous experiences learning a new language where I had "experts" available to mentor me) that it should've only taken a few months to maybe a year to reach that same level of competence.

    Of course, your mileage may vary (YMMV); I'm not the brightest candle in the candelabra as they my level of inefficiency is probably not very traceable to the capabilities of the programmers that the OP is concerned with.

    But that difference in what it "should or could have taken" versus what "it did take" is what I mean, in regards to learning Perl, by "efficiency". And therein lies what I consider to be the single biggest issue, one that I think the OP and the associated organization, need to understand and think about: learning by one's own "bootstraps" is workable, but the efficiency and effectiveness is significantly compromised.

    In that vein, I think the posted responses that accept that expertise is not available are useful and excellent, in my opinion, ideas on how to do "better" at efficiency and effectivenes in lieu of having real "expertise" available.

    The posts that suggest "you need an expert" are, in my opinion, absolutely correct if you are to have any efficiency or effectiveness in reaching the level of quality that the OP is looking for in a quick way.

    ack Albuquerque, NM
Re: Perl Test
by mickep76 (Beadle) on Oct 22, 2009 at 12:44 UTC

    Simply give them one or several task's, a limited time period and then review all the solutions.

    This will be a fair test since everyone get the same task and restrictions. Also it will give each developer freedom to choose how to solve the problem.

    And if you ask nicely we can give some free vouchers so they can join Perl Monks, free of charge!

Re: Perl Test
by Anonymous Monk on Oct 26, 2009 at 18:51 UTC

    This sounds like a management strategy that is doomed to failure. How can you effectively manage something when you haven't taught the skills to your engineers (or hired them, or hired a tech lead) and then try to tell them that they are doing it right or wrong? I would look at yourselves first and tried to see if you have done a good job managing a situation, because right now it seems like you are managing in retrospect, which isn't good.

    That being said, if everything is working, you could judge based on the survival of projects and whether or not certain projects have needed to be team projects or extended. If projects can be easily extended and worked on by multiple people, that's a really good sign for any language.

Re: Perl Test
by tweetiepooh (Hermit) on Oct 27, 2009 at 14:08 UTC
    Ask to see their documentation.

    You could also ask one developer to document the code of another, then compare the documentation sets. Is the code readable and understandable? "Clever" coders are not always the best.

    See how the code can be modified for new requirements? Are they building reusable code, modules. Maybe ask one developer to add a function to the program of another.

    Maybe ask them if there is one of their peers that they go to for Perl help.

Re: Perl Test
by whakka (Hermit) on Nov 06, 2009 at 18:05 UTC
    I was put in the exact position you mentioned two years ago. I was given the summer to study and learn Perl so I could do a gigantic data scrape on certain public data available online. To do this I spent a good deal of time with the Llama and writing toy programs. I am still the *only* person who even remotely knows how computers work, let alone able to program, in my office (I have a few peers but they are leaning in other directions).

    I had no programming experience or fundamental knowledge whatsoever (had never taken a computing class) and I have to admit the first year or so was really rough. Of course after those 3 months I knew enough to get by and make things work, but my fu was severely lacking. There are really two things though that motivated me: Perl programming was so much fun, and the Perl community was so generous, helpful, intelligent, and enthusiastic. This website is a testament to that - there really is nothing like it in any other field that I know of.

    I liked it so much that I started taking computer science classes at a local university. Although I've never heard a mention of Perl and there are no classes that touch it, learning computer engineering fundamentals, as well as OO with Java and Python, was probably beneficial. I don't know if this is an option for you though.

    Still, I really wish I had a Perl mentor at the workplace as well. I think my learning would be greatly accelerated (and I still have too much to learn). However having perldoc, perlmonks and a subscription to Safari Online have been a great boon, I can't recommend using these resources enough for learning the language and how to get things don't smartly and correctly. On perlmonks use the Tutorial and FAQ sections, and search some of the posts of the "great" monks - ikegami, tye, tilly, BrowserUK, moritz (and others) for whatever topic you're interested in. The other great resource is of course CPAN - getting to know the documentation through and through of the modules you use all the time is essential.

    Update: I just realized you asked for a metric. Here are two that I can think of:

    1. Make everyone (either individually or in teams) publish to CPAN. Just the process of designing, implementing, testing, and possibly maintaining a cohesive unit of work is good experience, even if the module isn't that great.
    2. Have coding competitions at the workplace, and make it fun! I really think there's nothing like competition to motivate people.
Re: Perl Test
by Anonymous Monk on Nov 07, 2009 at 23:34 UTC
    I like to ask, why you want to gauge the knowledge? Is it for salary increase, finding out their learning potential, deciding who is going to be team leader etc? I would just let them work in the team in any case.

    If you want them to become more useful to you, ask them to write tests for each others code. That way you can have better longer lasting code. You will have team that is greatly work in cooperating each other and appreciation for others. You might want to regularly introduce new books and provide better environment which are relevant to their work.

    The proper way to gauge the skills is to ask them to get more skills. It is beneficial to both.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://802677]
Approved by Corion
Front-paged by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (2)
As of 2018-05-28 04:09 GMT
Find Nodes?
    Voting Booth?