Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Seven habits of highly efficient perl coders

by Ryszard (Priest)
on Sep 17, 2003 at 11:55 UTC ( #292098=perlmeditation: print w/replies, xml ) Need Help??

I was thinking last night what made me think I'm an efficient perl coder. I had a bit of a Super and found this node, which co-incidentally is similar but not really what I was after.

After some careful thought I realised the things that I believe make me an efficient coder are not necessarily code specific qualities, but encompass a more holistic approach to banging out the final product. (The below list is not in any particular order).

When I say efficient, I don't mean banging out code on time and under budget, I'm talking about banging out code on time close to budget with the additional qualities of my code being easy to maintain, easy to expand, easy to replace in need etc etc. I'm not just talking about my lines of perl.

  1. Peer review
  2. Code reuse
  3. Good design
  4. Continual Learning
  5. Testing
  6. Teaching
  7. Documentation
To expand on the above points a briefly:

Peer review
I like to have others in my team and external to my workplace (eg PM) to look at my code, make suggestions and recommendations. It expands my experience and offers me the chance to learn new techniques, and to avoid bad ones.

Code reuse
Where ever i can, i attempt to extract core concepts out into standalone modules that can be used again and again, for example abstractions to data aggregation for reporting.

Good design
Obviously highly subjective, however in context an efficient design will lead to implementation on time, a solution that is maintainable and a end result that will make the project owners "happy" among a long list of desirable qualities.

Continual Learning
While similar to peer review, I take this a step further by experimenting with new things, reading journals, web sites and manuals/books.

Of course one of the things that makes me think that i am an efficient coder is testing. Writing automated tests, formal documentation with the aim of "Getting it right (tm)" without having to go back to the coding board tim e and time again.

While related to Continual Learning, I find that if i can teach my team new things, i benefit twofold. firstly, i get to re-enforce things I already know and secondly I increase the knowledge in my team so i don't need to necessarily complete all the code that needs to be done.

I like to document my code in pod and also inline. It helps me remember why i've done things, and why I've not done things. It reduces my time to revisit and understand code I've written before and not looked at for a while.

Of course there is quite a list of what can and does make an efficient coder, what additions/deletions would you make to the list?

update: fixed a bunch of weird (<deleted>) chars.

  • Comment on Seven habits of highly efficient perl coders

Replies are listed 'Best First'.
Re: Seven habits of highly efficient perl coders
by Abigail-II (Bishop) on Sep 17, 2003 at 13:47 UTC
    If those seven points work for you, great, but I don't think you can generalize them. I think I'm a fairly efficient coder as well, but I don't program in a team (I do work in a team, but while I program, I'm not a programmer), and a fair amount of the code I write (both for work, and privately written code) is designed to do one specific task. Let's see how your points work out for me.

    Peer review

    I don't have (Perl) peers to review with. I do peer review, but on a much higher level that reviewing code. I might review algorithms or strategies, but not code. My favourite reviewer absolutely hates Perl.

    Code reuse

    Most of the code I write are simple programs, doing a specific task. More often that not, there isn't much to factor out to modules. I sometimes, even write programs that don't have subroutines. If there's something that lends itself to be factored out to a module, I do so, but I'm not going the extra mile. I prefer delaying. If later I want to reuse something that I've done before, I can always make a module then.

    Good design

    Good design make *me* happy, but I also realize that my good design might not be someone elses. As for making the project owners happy, they usually want the result of the program, or the fact that there is a program doing "X"; as long as the result is there, good design is a bonus (or not relevant).

    Continual Learning

    No contest here.


    It depends. For many of my programs, testing is like testing a baked cake: the proof is in the eating. It's the end result that counts.


    Again this assumption efficient coders work in a team.


    Documentation is good, but often inline comments are good enough. Hey, if I write a program that creates a boot floppy - once I have the boot floppy with all its necessary files, the program is likely to never be used again. So, the POD isn't necessary.


      Again this assumption efficient coders work in a team

      As phrased and interpreted literally this is true. But *ahem* dont you teach here? Havent you been a teacher? Isnt your participation in the various perl forums a type of teaching?


      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
Re: Seven habits of highly efficient perl coders
by simon.proctor (Vicar) on Sep 17, 2003 at 14:05 UTC
    I work in a programmer team of one (me in case you hadn't guessed) and the other guys (HTML, CSS etc) just want the output of what I do. As long as it works they don't care.

    So I would have to go with Abigail and say teaching isn't really a habit of mine either. But then again, writing your own tutorials as a means of learning a new topic is a new twist (for me anyway).

    If I have to do something new, depending on its complexity I'll either write lots of small test applications (well commented) or extend these into a mini site detailing them in a tutorial way. I put these web pages up on my personal space at work alongside any HTML docs from the relevant technology.

    Works for me ;).
Re: Seven habits of highly efficient perl coders
by wufnik (Friar) on Sep 18, 2003 at 12:38 UTC
    after spending a good hour shocked by my failure to hurdle even the most elementary of the above habits, wondering what the hell i am to do when they are incorporated in the 'good programmer psychometric tests guide 2004', i saw the light:

    why not create my own list, inspired and flavoured by the field behaviour of the most inspiring, feisty, quirky hackers i know?

    why not create it, and make it the norm? whatever, dear monks, i must do something, or risk disencranchisement; here goes;

    Seven Habits for For Hackers of Independent Mind

    1: EMACS

    every independent hacker must have an attitude to the editor, whether pro or con. without this attitude, your credibility is seriously at doubt.


    was there ever such a stupidly over-architected way to print something? independent hackers recommend not using it.


    of course, there will be exceptions, but the windows-XP-rolling-hills-type-background is absolutely out. even pastel shades are preferable. of course, transparent_consoles++

    2: R.S.I.

    efficient hackers will, at the risk again of losing those esteemed efficiency brownie points (EP?), at least pretend to having this. advanced specimens have been known to type with their toes, RSI having become soooo bad.


    yes, and more, to type while eating pizza and not leave crumbs in the interstitial keyboard-spaces.


    perl -e '@}-`-,-`-%-'
    by Abigail II. enjoyable! pointless!


    my own is mariah carey. keep her away from me and my code! for every efficient hacker there must be some equal and opposite object, however innocuous, to counterbalance the phenomenal Yin each effective hacker brings to the world. keep the object, and the hacker, apart!

    unless your profile fits the former list of seven, stick with this! spread the word!


    -- in the world of the mules there are no rules --

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://292098]
Approved by broquaint
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (4)
As of 2023-02-06 07:11 GMT
Find Nodes?
    Voting Booth?
    I prefer not to run the latest version of Perl because:

    Results (33 votes). Check out past polls.