jesuashok has asked for the wisdom of the Perl Monks concerning the following question:
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Perl Exercises
by TedPride (Priest) on May 18, 2006 at 08:33 UTC | |
| [reply] |
Re: Perl Exercises
by GrandFather (Saint) on May 18, 2006 at 10:10 UTC | |
Code writing exercises are all very well, but something that is often neglected are debugging exercises. Start with code that exhibits various bugs and have your team find and fix the bugs. A valuable lesson along those lines is to present some code without strictures that is to be debugged. Bugs involving incorrect reference usage are particuarly good for this. If they don't figure out to add strictures for themselves, after they have struggled for a while add use strict; use warnings; and show them how to catch many types of error without even running the code. In the same sort of sense, reinventing wheels can often be good exercise. For example: CSV data is nasty stuff to parse. You could write a number of CSV data sets of varying nastiness and have your team write code to parse the data. Present the data sets in order of nastiness to see if you can break each itteration of the code. At the end of the day present a solution using one of the CSV modules to show why reinventing the wheel is a bad idea! DWIM is Perl's answer to Gödel | [reply] [d/l] |
by mikasue (Friar) on May 18, 2006 at 15:32 UTC | |
I have also learned a lot from reading SOPW entries to see what others have had problems with and how these were solved. I love this site! | [reply] |
Re: Perl Exercises
by idle (Friar) on May 18, 2006 at 07:42 UTC | |
| [reply] |
by mikasue (Friar) on May 18, 2006 at 15:34 UTC | |
| [reply] |
Re: Perl Exercises
by Herkum (Parson) on May 18, 2006 at 12:55 UTC | |
If you are going to mention bugs, why not focus on writing tests? It is amazing to me that this area is so broadly ignored by programmers. An even better place to start would be writing modules that would follow the format of a CPAN distribution. Requiring a, The tests get them into the good practice of writing interfaces for their code instead of writing code and then try to figure out how the interface works. It gives them examples of how to write code in general. To often I see programmers write modules without any documentation, working examples, testings or ANYTHING THAT IS NOT CODE! It leads to crappy, buggy and ultimately unmaintainable code. Why? Reading code is hard, when code be explained in english in a few sentences and be read in a minute might take 10 or 20 minutes of reading code to figure out how it is supposed to work. The reason for this is code has no frame of reference, writing documentation is supposed to do that. | [reply] |
Re: Perl Exercises
by blazar (Canon) on May 18, 2006 at 09:50 UTC | |
NOTE: Each Exercise should take atleast one day of time to finish. Gawd! I would hardly call an exercise that "takes at least one day to finish" an exercise any more. I would call it a complete program/project/framework, etc. | [reply] |
Re: Perl Exercises
by ptum (Priest) on May 18, 2006 at 16:00 UTC | |
If you are "leading a perl Team of 7 members", why do you need to test their knowledge? Seems like you would do better to teach first (if you have the ability yourself) than test them on something they don't yet really grasp. When I first began to use Perl, I received some minimal formal instruction and then was almost immediately responsible for the oversight of the work of 8 or 9 other developers. Rather than try to emphasize the gulf between my 'knowledge' and that of the rest of the team, I organized a weekly code review and seminar in which I encouraged others to teach what they had learned over the course of the week. While I still did much of the teaching, I found that many of the developers grew rapidly in their enthusiasm and understanding of Perl as they were permitted to learn through teaching. Sometimes I had to gently correct, and sometimes we all rushed off doing the wrong things in the wrong way (with my ignorance compounding theirs). We grew closer as a team and I learned a lot along the way. I don't think there is any substitute for learning while doing real work. Why not divide your next project into manageable chunks and parcel it out to your team members? If you spend some serious time on code reviews (and adopt some of the write-to-test advice you received from Herkum) you'll make good progress on your project and teach as you go. No good deed goes unpunished. -- (attributed to) Oscar Wilde | [reply] |
Re: Perl Exercises
by Anonymous Monk on May 20, 2006 at 12:07 UTC | |
[reply] |