Speedy Hacking

Replies are listed 'Best First'.
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
"Speedy Hacking" is especially useful in the Unix Sys Admin arena, probably more so than in a "real" Software Engineering context. There are often times when a quick and dirty sh/awk/perl script can save the day. A few examples: Quick hacks during system outages: ps -elf \| sort -rn +9 (find top memory pigs) Being able to cobble up an LWP script to page you when a backup is finished, allowing you to work on other items in the meantime Various uses of perl hashes and sort() on log files. Perhaps to find out very quickly which IP address is flooding your webserver during a hack attack. Perhaps to answer some last minute question for a Marketing VP. ( Who are the top 10 domains for the email addresses on our mailing list ?) More quick and dirty perl, like filtering and summarizing sar output when your Oracle database is sucking wind, and some Business Analyst is breathing down your neck.	[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]