http://qs321.pair.com?node_id=43232

Hi,

So I got to thinking that I'm not, perhaps, the most "productive" programmer out there. By that I mean that I don't practice efficient development techniques as well as I should. ie. I type when copying and pasting would do (this is noticeable when writing 150-200 stored procs where I keep retyping field and table names), and in general I don't think I'm familiar enough with the development tools I use (as in the editors and IDE's) to take maximum advantage of the time saving features they offer.

That said, I'm working on making improvements in my "productivity" with the tools I'm using. Currently I'm using Powerbuilder at work (ugh), and Perl and Python for my own projects and private consulting. At this moment, I've been spending more time in Windows using Editplus 2 (which so far seems to be a really neat tool for Win32 coding).

So fellow monks, I ask for your wisdom. What do YOU do to save time when coding? Whether it be in the editor/IDE, the language itself (Perl, Python, Powerbuilder, C, or whatever language you've learned an interesting time-saver), or in getting a solid 8 hours of sleep every night :), I'd be interested to see what you do to keep your development speed maxed.

-- mothra

Replies are listed 'Best First'.
Re (tilly) 1: Development Speed and Productivity
by tilly (Archbishop) on Nov 24, 2000 at 21:41 UTC
    Cutting and pasting results in false productivity! Sure, you get something done now, but you are slowed as time goes by.

    The majority of time and money is spent in maintaining code. Time spent making code maintainable pays off again and again. A well thought-out module allows faster code-reuse than proficiency with pasting, and is more maintainable to boot.

    For some real productivity try getting enough sleep, then learning from books like Code Complete or The Pragmatic Programmer. An interesting tidbit from Code Complete. The most productive programmers spend substantially less time coding than others. Instead they spend time in design, discussion, testing, and other activities.

      As I mentioned, the copying and pasting was referring to, in this example, writing stored procs. ie. If I'm writing a proc where I have the query:

      SELECT s.first_name, s.last_name, s.date_of_birth, tm.highest_mark
      FROM T_STUDENT s, T_TEST_MARKS tm
      ...etc...

      And then later I want to do another query using some of the same fields, I used to retype the field and table names, even though copying and pasting them would be much faster (of course :). I certainly wouldn't keep copying and pasting functions or other "I-want-to-be-in-a-module" types of thingies into several different scripts/programs/whatever you want to call them. After all, that's what modules are for. Not to mention that copying and pasting code (with the idea "hey, this almost does what I want, I'll just c/p it here and make some changes!") is very dangerous. :)

      -- mothra

        I have had to do similar stuff before I wrote an perl application to create the SQL from the database directly. Point it at a table (or two) and it creates the select then edit the select. This is probs better than cut/paste. -- Zigster
Re: Development Speed and Productivity
by neophyte (Curate) on Nov 24, 2000 at 20:40 UTC
    I try to increase my productivity by using a small note manager to order and keep functions for re-use (on win32). So I mostly start coding with a session of excessive c/p-ing and connecting things together.
    I just use a text - editor for coding (vim / proton for links check my homenode).

    neophyte

    update: Of course I don't c/p big functions, more sort of snippets like a frequently used regex or assigning a german layout to a date. With bigger functions you might end up spending more time adapting it to what you really need than writing it from scratch would have taken.
Re: Development Speed and Productivity
by clemburg (Curate) on Nov 27, 2000 at 17:01 UTC

    First, I'd like to follow tilly in recommending Code Complete and The Pragmatic Programmer. (As an aside, I wrote a little script that spits out a random tip from the Pragmatic Programmer book, much like the fortune program.)

    That said, in my personal practice I strongly believe in these productivity boosters:

    • Use whiteboards. Learn to analyze and design in a team.
    • Use one good editor (emacs or vi) very well. Learn it. Extend it. Use it all the time. Use regular expressions to do repetitive editing tasks. Filter your text through perl programs. Etc.
    • Use code generators. Perl is the perfect tool for this. E.g., generate the SQL for a database structure and the client code to access the database from a common meta-language.
    • Use other well known UNIX productivity booster tools like make, expect, etc.
    • Use version management (e.g., cvs) all the time.
    • Never use copy and paste. Instead, automate the needed editing task using Perl or your favorite editor.

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

      I agree with all of the previous points, the book references are excellent. Just to add a further point, one of my favourate sayings (that I may have ripped off but I dont recall) is that a good programmer is a lazy perfectionist, be lazy love it live it, you are using a puter if it is hard you are doing it wrong, find another quicker way to do whatever you are trying to do. Let the puter take the strain.
      It often takes longer to find and impliment the 'quicker' way but in the long run you will be in a better position for next time.
      It is in the application of just this sentement that I use perl, a fab way for me to be lazy.
      -- Zigster
      That little Pragmatic Programmer script is really cool :) Now I think I'll buy the book!
Re: Development Speed and Productivity
by gregorovius (Friar) on Nov 25, 2000 at 04:10 UTC
    I use Xemacs, and am very fond of its keyboard macros feature. You can search for substrings or regexps within your keyboard macro and do things like converting a list of names into a list of variable assignments, in one keystroke, saving lots of typing time.
    Ctrl-x-( # start macro recording Ctrl-x-) # end macro recording Ctrl-x-e # execute macro Ctrl-100 Ctrl-x-e #execute macro 100 times
      This is indeed handy, and vi folks should know how to do this too. In vim (my vi of choice), it goes like this:

      qa # start recording to buffer a; # your choice of buffers: [0-9a-zA-Z"] q # end macro recording @a # execute macro a 100@a # execute macro a 100 times

      Same thing, really... only fewer keystrokes. {grin, duck, run}

Re: Development Speed and Productivity
by mrmick (Curate) on Nov 24, 2000 at 23:13 UTC
    I have gotten into the habit of writing templates for things that I do often (more than about three or four times) and building libraries of subroutines that I can call when the same thing has to be done again. These could be simple subs to open a file for reading and return any errors or simply a special print statement.

    Once I have a few of these that are related and if it seems plausible to me, I then will create a package and store it as a module.

    One pitfall is that if I have to share my code with anyone else, I have to ensure that they get the files I have referenced.

    I have these libraries because I am really lazy. I also have horrible typing skills.

    Mick
Re: Development Speed and Productivity
by FouRPlaY (Monk) on Nov 25, 2000 at 04:21 UTC
    I have two letters for you: vi.



    FouRPlaY
    Learning Perl or Going To die() Trying
      I use Emacs and Vi, using either of these, well, makes you productive. Touting one over the other is never productive. More productive would be for vroom to add a library of FAQ (Flames, Anathemas, Quips), to factor out repetition ;)

      I have a one-liner library of perl commands, idiomatic lines..stuff that is too small or generic to justify being in a function or object, respectively.

      Being a sick puppy I'll some-day put it into CVS so I could refine the code as I comprehend more. This may make for one liners that are tricky to read, I comment the code.

      In defence of my last statement: one place I used to work used a convoluted code generator that produced C code, invariably with 3 levels of redirection, soon everyone could read it, it took exposure to it.

      Part of my productivity issue is I try to write terse comments like merlyn's replies to postings.

      "It takes me an age to strip out the unnecessary stuff." =~ "being concise takes time"

      --
      
      Brother Frankus.
      OK so I am guessing an editor war would not be welcome here ;-) I would recomend looking at vim tho if you were new to the editing world. It has a very very snazzy perl interpretor built into it, it allows you to run perl over the current buffer (amongst other things). I am an emacs head really, but the idea of running perl in an editor has long been one I think has wings. Shame I am too stuck into lisp atm ;-(
      -- Zigster
Re: Development Speed and Productivity
by Anonymous Monk on Nov 28, 2000 at 18:55 UTC
    My tip #1: avoid poxy middleware that makes you edit everything in a poxy little Java application that is even less good than an html textfield. The bloody thing doesn't even scroll the window to follow the cursor. And the horizontal scrollbar disappears if you're not at the bottom of the window! So to scroll across you have to scroll all the way down first!

    It's driving me mental.

    andy. (getting back in box now)
    p.s. and you can't even do Select All!