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
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. | [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
|
That little Pragmatic Programmer script is really cool :) Now I think I'll buy the book!
| [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] [d/l] |
|
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} | [reply] [Watch: Dir/Any] [d/l] |
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 | [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] |
|
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. | [reply] [Watch: Dir/Any] [d/l] |
|
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
| [reply] [Watch: Dir/Any] |
Re: Development Speed and Productivity
by Anonymous Monk on Nov 28, 2000 at 18:55 UTC
|
| [reply] [Watch: Dir/Any] |
|
|