One of the coolest things that I like seeing at work is a really good programmer (ie. my supervisor :) do what they do. They dance around the editor knowing exactly what they're looking for, exactly how they're going to fix the problem, and before you even understand what's wrong, they've already fixed it!
Needless to say, this is the programmer I aspire to be. In complete command of what I'm doing, rather than "programming by coincidence" as I seem to stumble into doing too often, in a rush to meet deadlines.
Obviously, there's more to writing good code than writing it quickly, but in spite of that, it's a trait I'm really trying to develop. It seems that there are many factors that get in the way of providing quick answers though, namely wrapping your brain around business logic, figuring out what the guy was thinking when he wrote the code you're maintaining and, of course, the complexity of the problem.
My question to you, fellow monks, is how does one know when one is a "fast enough" programmer?
I started (and fell in love with) programming with a 1.5 year college course in March '99, and have been working in "the industry" for 6 months or so, but I still feel that my skills and certainly my speed as a developer are vastly inadequate. Am I being to hard on myself? Do other monks feel this way? What's a monk to do?
Re: Speedy Hacking
by Adam (Vicar) on Feb 09, 2001 at 07:03 UTC
|
Obviously, there's more to writing good code than writing it quickly, but in spite of that, it's a trait I'm really trying to develop.
I think you have it backwards; that is, I think the ability to locate and fix bugs in code quickly is a symptom of both a skilled programmer and a quality code base. The speed isn't really the goal, its just a happy side effect.
To illustrate my point, I once worked on a large program that was a sort of parsing tool which was used "in-house" to assist with creating our product. I was a bit of a newbie, and so I was given the task of fixing a few, "minor", bugs in the code base. Unfortunatly I continuously got lost in the code and started getting very frustrated. So I took it to a co-worker, a talented programmer with 20+ years of experience, but he too was unable to explain what the particular chunk of code was doing, despite an abundance of comments and documentation. It wasn't me, the programmer, that sucked, it was the code base.
Fast forward to more recent times... My latest project is a data processing server handling a variety of input formats. My co-worker, who wrote a large portion of it, went on vacation, and I had to fix a couple bugs in it. The quality of the code generated by my co-workers was very good, and that combined with my knowledge of the programming language has enabled me to determine the causes of the bugs, come up with solutions, and have them ready for our test department very quickly. Same programmer, but a much better code base.
The point is not to worry so much about being able to hack quickly, but rather to gain experience reading other people's code and writing your own quality code. It might take you longer to design, write, and test a quality product, but when it comes time to fix a bug or add a new feature, you will be able to do it just as fast as your boss.
| [reply] |
Re: Speedy Hacking
by tadman (Prior) on Feb 09, 2001 at 06:04 UTC
|
In the spirit of the "Perl Monks" theme, here's my take on
the "fast enough" question with reference to Zen teachings,
here presented as a paraphrased version of
the comments of another monk, Takuan Soho, on
learning:
You need to realize that when you practice from the state of
the beginner all the way to the stage of immutable wisdom,
then you must go back to the status of the beginner again.
Let me explain in terms of Perl. As a beginner
you know nothing of statements or regular
expressions, so you have
nothing in yourself to dwell on mentally. If someone
asks you to program, you just program
without thinking of anything.
Then, when you learn various things like packages,
how to wield
a regular expression, where to place your attention, and so on, your mind
lingers on various points, so you find yourself all tangled
up when you try to code.
But if you practice day after day and month after month,
eventually statements and structure don't
hang on your mind anymore,
and you are like a beginner who knows nothing.
Zen teachings advocate a position of doing without thinking,
which is to say that only when you can program without thinking
about programming can you claim that you can really program
at all.
Learning Perl is like learning any language, and you have
really only learned that language when you begin to think
in that language. You're "fast enough" when you don't have
to think about Perl at all and you can just program. | [reply] |
Re (tilly) 1: Speedy Hacking
by tilly (Archbishop) on Feb 09, 2001 at 09:37 UTC
|
I would like to second Adam's comments. There is a world
of difference between being able to pound out code, and
being productive. In fact things you would think are good
measures, lines of code written, bugs fixed, and so on, are
actually highly misleading.
The worse the code you are cranking, the easier it is to
crank it. Furthermore the higher the bug counts. But they
are all simple bugs so they are easy to fix. Thus giving
the illusion of a highly productive programmer.
However when you attempt to measure productivity by
producing a measure of how long it takes to get the same
task done, the most productive coders spend the
least time actually typing code. Instead they spend time
on activities like design, review, and so on that head off
bugs before they start. When you consider that the
majority of your time is spent in repairing code, when you
just race ahead it is like paying in credit. You will have
to pay back with interest before you are done.
If you want to understand more about productivity, I
strongly recommend Rapid
Development : Taming Wild Software Schedules by Steve
McConnell. (Glancing through the reviews I am surprised
that there are as many 4's as there are. Oh well) Of
course at your stage you might benefit more from
Code Complete by
the same author.
Now you have indicated in the past that you think I am just
a Linux troll. So let me point out up front that those
two books I just recommended for you are published by
Microsoft Press by an author who works as a consultant for,
among other companies, Microsoft. They also have some of
the best advice that I have ever seen on how to program
well. I don't believe in turning down good advice just
because I dislike the source. I strongly recommend that you
not turn down this advice either. | [reply] |
Re: Speedy Hacking
by Trinary (Pilgrim) on Feb 09, 2001 at 05:29 UTC
|
I think you're 'Fast Enough' just before the point at which the speed at which you program adversely affects the speed at which you get things done.
Sometimes coding something supremely fast slows down debugging time, thinking things out and having a plan of attack is the key here...once you know 'how' to do it, getting it done is usually simple. The more functional the model you build before you open vi, the better your structure will be laid out, the better you will know what's going on, and thus the faster you will be able to fix problems. Just coming up with a series of steps and coding them all out at once without thinking about degeneate cases and such means when something goes wrong, you often have no idea why.
I think when you describe the speed of a 'really good programmer' it's because they have a mental picture of what pieces should be doing what, that they implicitly understand. This is partly because of deep familiarity with a language like perl, and more generically, because they know how to design stuff well. It's a skill that's extremely valuable, and one that I'm trying to develop as well. Enjoy. Trinary | [reply] |
Re: Speedy Hacking
by kschwab (Vicar) on Feb 09, 2001 at 05:48 UTC
|
| [reply] |
Re: Speedy Hacking
by epoptai (Curate) on Feb 09, 2001 at 06:17 UTC
|
One way to write good code quickly is to not have to write
it. Some of my strategies are:
- import modules and use their code.
- have a well-stocked/sorted library of code snippets,
useful subroutines, and templates.
- use a good editor and configure lots of perl syntax
shortcuts.
My feelings of being somewhat "fast enough" coincided with
gaining a level of fluency in the language that allows
some thinking according to it's rules leading to activities
like coding working programs with pen and paper. As with
any learned skill you have to do a lot of slow and
thoughtful work to gain the skills required for competent
and speedy execution.
| [reply] |
Re: Speedy Hacking
by arhuman (Vicar) on Feb 09, 2001 at 12:47 UTC
|
I started (and fell in love with) programming with a 1.5 year college course in March '99, and have been working in "the industry" for 6 months or so, but I still feel that my skills and certainly my speed as a developer are vastly inadequate. Am I being to hard on myself? Do other monks feel this way?
Be patient mothra.
It take a long time to be a good programmer, I mean not only knowing perfectly the syntax but be proficient with the idioms of the language...
And if you want to have a wide programmer background you'll have to count in years...
Yes I feel like you do, I'm a learner.
Even if I've been playing with computer since 1985 (anyone remember the TI99/4A or the ZX81 ?) All I know now is that even if I spend the rest of my life stuck on my computers 10 hours a day, I'll always be a learner : New Os, New Languages, New buzzwords (even if it's often old concepts...)
But anyway, as long as I enjoy learning and to see my skills increase, the computer-guy path will be my Path.
BTW stay humble as you are, for it's a common virtue among GREAT programmer.
Good luck, and enjoy...
| [reply] |
Re: Speedy Hacking
by zigster (Hermit) on Feb 09, 2001 at 17:00 UTC
|
Speed is an strange thing to measure. I am proud of the fact that I write code very slowly, very very slowly in fact. I frequently rewrite and adjust code to suit its purpose. I spend a lot of time thinking about what I am doing and being sure that the design is up to the job. I am proud of what I produce and I think the effort I install into the production pays dividends. I also note that in the time I take designing and rewritting and generally fiddling is time I save 10 fold in debugging and maintence. Take an example, I recently was tasked with writting a trivial app and given a week to write it. I took two. The next complex app I had to write was given 2 weeks I used the code base of the first app and wrote it in 2 days. I spotted early on that there were repeating constructs in all our servers so abstracted them away initially. This design will save time on every similar server I write at this position..
Dont aspire to be fast .. aspire to be good.
--
Zigster | [reply] |
Re: Speedy Hacking
by clemburg (Curate) on Feb 09, 2001 at 15:59 UTC
|
I agree with Trinary - you are fast enough when you can code fast enough to keep up with the evolution of your mental model.
But honestly, writing code fast is not a big thing. It is much more difficult to decide on what to write.
Also, often you will find that *not* writing, but first *thinking* will help much, much more.
The proof of intellect is to avoid doing simply the next best. (Alfred Bester. Demolition. Goldmann, 1999, p. 24. Original: The Demolished Man. 1953. Translated from the German edition.)
Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com
| [reply] |
Re: Speedy Hacking
by McD (Chaplain) on Feb 09, 2001 at 23:42 UTC
|
mothra writes:
They dance around the editor knowing exactly what they're looking for, exactly how they're going to fix the problem, and before you even understand what's wrong, they've already fixed it!
Hrm. Sounds to me like a description of a programmer who
knows both the code base, and the editor.
In other words, know your tools, know the existing code.
Knowing the code you seem to have a handle on, and others
have spoken on it as well. I'll offer this meditation on tools:
One danger of tools is that once you become proficient with a tool,
you won't want to learn new tools - that way lies the
scorched earth of the vi/emacs battlefields, and the endless
holy wars of language advocacy. Be wise enough to see past
those.
Of course, Perl is a tool too. :-)
Peace,
-McD
| [reply] |
Re: Speedy Hacking
by Anonymous Monk on Feb 10, 2001 at 10:00 UTC
|
having worked in tech-support for several years and recently moved
over to engineering, I would say.....Worry first about quality and
second about speed! Re-solving problems is not fun.... | [reply] |
|
|