Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
The stupid question is the question not asked
 
PerlMonks  

Taking care of your tools

by g0n (Priest)
on Mar 11, 2005 at 14:05 UTC ( #438641=perlmeditation: print w/ replies, xml ) Need Help??

People who perform skilled manual jobs, like carpenters, mechanics etc, often take great care and pains over their tools - cleaning and oiling, sharpening, organising etc. It occurs to me occasionally to wonder what the parallel for programmers is. Although I've been fighting the temptation for a year or two to replace the plastic housing of my laptop with something nice in polished wood, the obvious candidates are code libraries and skills.

The subjects of 'what to learn' and 'how to learn' are discussed here regularly, so the 'skills' element is fairly well covered, but does anyone have any favourite techniques, methodologies, or even better modules for maintaining, organising, indexing, 'cleaning' and storing their libraries, code examples, notes about algorithms & techniques etc?

VGhpcyBtZXNzYWdlIGludGVudGlvbmFsbHkgcG9pbnRsZXNz

Comment on Taking care of your tools
Re: Taking care of your tools
by pboin (Deacon) on Mar 11, 2005 at 14:09 UTC

    Three things:

    • Version Control
    • Version Control
    • Version Control

    Seriously. It doesn't matter whether you use cvs, subversion, or even something else. It's not only useful for going back to see edits, I find it has an unintended consequence: It enforces discipline and makes me *think* about what goes into that treasure-box and get marked with my name, my work, and my comments. (Versus just some random file laying in a directory somewhere...

      It's so funny you mention this. I literally just finished going back through a clearcase repository to do some forensic analysis on a change. The history goes back to before 2000. The changes I was looking for happened as early as November, 2001.

      Since there is very little developer documentation and nearly every person on the product back then has moved on, the source control and being able to diff various versions is the only way I can come up with a reason behind why certain changes were made.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

        Which leads to another suggestion: Document your code; and don't be afraid to leverage whatever tools you can find to make it easier and thus encourage you to do it. (You'll thank yourself later!) For starters: learn POD; learn Doxygen (or similar); learn what Literate Programming is.
Re: Taking care of your tools
by dragonchild (Archbishop) on Mar 11, 2005 at 14:27 UTC
    The tool you will be using most often is your editor. Pick an editor and learn it inside and out. Every single editor will perform the main function - put text into a file. Every single editor worth talking about will give you shortcuts. It doesn't matter if it's Komodo, Emacs, or some vi clone. Pick one, stick to it, and learn it as well as you can. After 10 years, I'm still learning new tricks for vi.

    Testing is another tool you should be using more than you already do. Your test suite is your preventative maintenance. This is what keeps you from screwing up. A friend of mine helped me change my brake pads recently. When we took the tire off to get to the pads, he put it right under the car. When I asked him why, he countered with "Is it cheaper to get a new rim or a new axle?" That's a test case for mechanics.

    CPAN is another tool. Recently, someone like japhy wrote a module to fulfill a request (Techniques On Saving Memory). Turns out that not one, but two modules were already on CPAN that did what japhy wrote (though the APIs for each were different). Granted, it was only 30 minutes and japhy probably enjoyed them. But, what if you write your own connection to a database (DBI) or templating module (Template) or web application framework (CGI::Application)? That's not 30 minutes. In some cases, that's 30 weeks and you still won't get it right. And you have to maintain it on your employer's dime.

    Keeping with the CPAN idea - learn how to use the modules you do use. Did you know that you can pass in a reference to a subroutine as a <TMPL_VAR> to HTML::Template and it will behave as a callback, even within a <TMPL_LOOP>? That was a feature someone was asking for recently and was considering junking H::T because "it wasn't there". Yet, it was there (just documented in a confusing way). That's huge!

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Re: Taking care of your tools
by trammell (Priest) on Mar 11, 2005 at 15:21 UTC
      One of my tools is my brain, so I make sure to "sharpen the saw" from time to time.

      Sharpening a saw by hand is a difficult, slow, and risk-prone activity. If you mis-align the teeth, you may end up with a duller saw than when you started. If you apply force in the wrong place, you may break the blade altogether.

      Sometimes it's just cheaper and easier to buy another saw blade, or even another saw. In the context of programming, that would be consultation or collaboration with a co-worker, or perhaps hiring someone new...

        Sharpening a saw by hand is a difficult, slow, and risk-prone activity. If you mis-align the teeth, you may end up with a duller saw than when you started. If you apply force in the wrong place, you may break the blade altogether.

        Just to stretch the metaphor, I wonder what sort of activity might be comparable to "breaking the blade". Probably the closest thing in my life is burn-out from a rotten job environment. Had me seriously considering an occupation change.

      Rats... beaten to it again! :-D That's a good link!

      Seconded. While I heartily agree with all the comments on editors and HDD backups, my mind is my most important tool. Whenever I'm hung up, I back off and examine the attitudes that frame the context of my attention.

      Be it the way I'm iterating over a file, the tool I choose to approach a task, my attitude towards that task, or how I see myself in relation to a programming team, I constantly have a background thread in my mind looking for stressed nodes that indicate improper framing.

      In programming, things are just taking too long, either to run or to code. In attitude, either heat or 'tiredness' are present when there's a mental bugaboo present. In relationships with others, I look at what I call my teammates subconsciously. Are they partners or are they problems?

      If your mind is clear, your code will be clear.
        If your mind is clear, your code will be clear.

        A minor nit - If your mind is clear, your code can be clear. I'm pretty sure Damian Conway's mind is very clear, but I'll be damned if his code is! :-)

        Being right, does not endow the right to be rude; politeness costs nothing.
        Being unknowing, is not the same as being stupid.
        Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
        Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Re: Taking care of your tools
by Anonymous Monk on Mar 11, 2005 at 15:33 UTC
    Stay familiar with the tools you use most often (for me, my shell, my editor, Perl, C, LaTeX, Solaris). Even after more than a dozen years of intensive usage, I still reread the documentation of my editor every know and then (once every 1 to 2 years). Not to look something up, no, from top to bottom. Sometimes, I pick a Perl manual, and reread, top to bottom. Even if I know it already. I can advice that to everyone (and if you do, send a patch for every typo, grammar mistake, omission, wrong example, whatever, you find - you're much more likely to spot them then, then when you're browsing it for a particular piece of info). Other manuals (or books) I've reread multiple times, just for the sheer joy of rereading include the bash manual, K&R, and The UNIX Programming Environment.

      Seconded. 14-ish years later and there's still gobs of stuff in Emacs that I still don't know that it could do. Just the other day I found Skeleton mode. C-h i and just browsing can be fruitful.

Re: Taking care of your tools
by artist (Parson) on Mar 12, 2005 at 00:45 UTC
    My favorites techniques:
    1. Use Emacs, look for easier methods:Currently looking for integration of CPAN, perldoc etc ..
    2. Read Perlmonks regularly, contribute where possible.
    3. Browse CPAN modules directory
    4. Read c.p.l.m sometimes
    5. Browse the web for the novelty of technology and try to replicate that to the extent possible.
    6. Keep up with hotest trend in tech to the extent possible. (Now, not easily possible when you gain proficiency in some skillset).
    7. Use version control mechnism.

    Want to work with more techniques such as..

    1. Do code in terms of algorithms.
    2. Testing
    3. Project design and planning.
    4. Read opensource projects
Re: Taking care of your tools
by zentara (Archbishop) on Mar 12, 2005 at 13:34 UTC
    Make frequent backups of your "code-snippets" library, just in case the hard drive goes; and a related suggestion....keep your hard drive cool.

    I'm not really a human, but I play one on earth. flash japh
      At risk of descending into the traditional backup rant, it's not just if the hard drive goes. Many of us use laptops, which are (as I know only too well, see below) a magnet for scumbags, ne-er do wells, and thieves of all sorts.

      Irritatingly, so are CDs, so don't store your only data backups on the CD rack next to the collected works of Britney! For my part, I keep a 'core' of absolutely vital stuff in a particular directory, ruthlessly keep it below 256MB, and back it up onto a pen drive on my keyring 1ce a week, as well as other backups. When working on something important I periodically email it to an offsite location (home if at work, work if at home).

      Two weeks ago that habit saved me from disaster. My laptop was stolen at the end of a weeks holiday, taken specifically to work on my dissertation. 4 days later I had replaced it and retrieved the copy of the document I had mailed to work - without a single word lost.

      g0n, backpropagated monk

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://438641]
Approved by RazorbladeBidet
Front-paged by jdporter
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (13)
As of 2014-04-18 13:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (468 votes), past polls