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

I noticed something this morning. Good code feels good - for whatever my definition of good is worth. I had been struggling with the beginnings of a large project and how to handle error conditions. Things were complicated and brittle. Lots of code existed to handle potential problems, obscuring the main goals. I couldn't seem to avoid multiple global variables, it was clear that changing things later would require updates in multiple places, … Things were just generally yucky.

Then I figured out what to do. As I implemented it everything became simple(er) and robust(er). Lines of code dropped, what was left was easier to understand, long range coupling decreased. All was good in the world. (Why it took hours to settle on essentially die and warn and their associated sig handlers is something I'd rather not discuss <sigh>).

But I could literally feel that it was good. The code flowed and the structure was apparent. I didn't have to fight the language or logic. Stuff just happened, and with fewer keystrokes, fewer variables, fewer loops, etc..

The same thing happened earlier when I realized I needed a multilevel hash with coderefs and qr'ed regexes. Once I implemented that, some subs lost half their lines of code. Of course, after the fact, I realized that I was just implementing 'good coding practices' by moving things to data and utilizing features of the language in standard ways. But that was after I did it. The intuition came first, the analysis followed.

This is doubly interesting to me because it jives with how I view what I do in my real life as a graduate student in physics. There is a common view that the sciences proceed in an analytical way, with each step taken for consciously recognized reasons, like the derivation of a mathematical proof. That a researcher sits down at his desk or in front of her experimental apparatus and slowly and relentlessly and logically 'derives' new facts about the world.

From my experience this is complete hogwash. It doesn't work like that at all. What really happens is that you (well, I guess I can only say 'I', can't I?) flounder around in the dark, with vague notions of where you are and where you're going. You try various things that you're not at all sure will work. You try to fit various theories to the problem at hand.

After a few false starts you begin to see how things work, and you try a few more focused experiments and then you understand. Only after that do you construct a specific theory, set up clear and persuasive experiments, and 'derive' your conclusions from commonly accepted axioms.

Well, so much for my ramblings …

Which way do you program? Relentless logical derivation or intuitive-casting-about-with-a-helping-dash-of-pre-and-post-hoc-analysis?

How much time do you spend consciously thinking things like 'I need to decrease coupling', 'This logic is too complicated', etc. and how much time do you just do it and go where your intuition says?

Replies are listed 'Best First'.
Re: Code that feels good
by scain (Curate) on Aug 24, 2001 at 22:49 UTC
    scott,

    If only I could give this more that one vote... At any rate, a hearty thumbs up on expressing so eloquently a feeling that I often get, both when writing code, and back when I actually worked in a lab. After stumbling around awhile, a little light clicks on, and I "get it". I imagine it is that way for many people.

    A somewhat related quote (from whom, I can't remeber; anyone?) is something like "more real science|progress|discoveries begin with the phrase 'that's strange' than with 'Eureka!'". For me, plodding around is a necessary step.

    Thanks,
    Scott

Re: Code that feels good
by Boots111 (Hermit) on Aug 25, 2001 at 01:16 UTC
    What you have expressed here is one of the central themes to a book that I just finished reading. While I will not go into the whole book's story right now, I will say that Zen and the Art of Morotcycle Maintenance contains many bits of philosophy that apply to programming as well as life in general.

    While the book has no actual focus on coding, it does begin to explain the mental processes of creativity and scientific method, and as such will make you a better coder. I highly recomend it, as it will help you explore this thought which you have just scratched the surface of.

    Matt
      And the second book by Pirsig "Lila" is equally good ;-)
      A much fuller explanation of what he means by "Good" and "Quality".

      Billy

Re: Code that feels good
by hsmyers (Canon) on Aug 25, 2001 at 00:22 UTC
    A bit of both. It depends on how many times I've done the solution to the problem at hand. And how familar I am with the problem domain. The more experience/familarity I have, the more time I spend trying to improve the code. I have to admit that I don't ever remember saying 'I need to decrease coupling' though—usually it's more along the line of 'This code sucks!' or 'What the hell was I doing there?'

    When I start on something new, I spend most of my time doing research. Then when I have some slight clue, I proceed to implement my newly acquired vague notion. I tend to do this in a top down fashion and I iterate the code until I've achieved some minimal goal (i.e. like 'Ok, this works, now what?) One thing I do as I move (hopefully forward) along, is review the code that I've written. This is particularly handy if I'm stuck on some feature or solution, since I can switch to improving existing code as a break from pondering problems. Often a side effect of this disjoint approach is that my subconscious mind manages to come up with the needed answer/s.

    hsm
Re: Code that feels good
by japhy (Canon) on Aug 25, 2001 at 00:42 UTC
    I'm about to feel that way about my regex parser. I figured out a way to make it much faster, and much easier to read. While my regex parser (and related modules) are my <language type="french">chef d'ouevre</language>, they are hideous to look at, and I'm embarrassed enough that I'm not going to show it to people willingly.

    I usually code well, though. I have a clear idea of the task, and how to solve it with Perl. When I started learning Perl, though, I was silly and awkward. ;)

    _____________________________________________________
    Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

Re: Code that feels good
by Anonymous Monk on Aug 25, 2001 at 01:46 UTC
    Having just convinced a co-worker that:
    print join('^',split(/\s+/,$_)),"\n";
    was much nicer than
    my ($field1,$field2,$field3) = split(/\s+/,$_);
    print "$field1^$field2^$field3\n";
    I can say that code can feel good. ----
      print join('^', /\S+/g), $/

      ... feels even better :-)

         MeowChow                                   
                     s aamecha.s a..a\u$&owag.print
Re: Code that feels good
by Fingo (Monk) on Aug 25, 2001 at 00:58 UTC
    When I write something I usualy have a few basic goals, and figure a way to complete them. My code becomes a complete mess and hard to read, but I have clear solutions to my problems. Then I do a complete rewrite paying attention to details an dmaking it logical. So I guess I start out useing intuition and then move on to logic.
Re: Code that feels good
by ralphie (Friar) on Aug 25, 2001 at 03:58 UTC
    this is totally off the wall, but reading your post reminded me of a song by guy clark (a great songwriter) which strikes me as pertinent. the refrain goes ..

    stuff that works
    stuff that holds up
    the kind of stuff you don't hang on the wall
    stuff that's real
    stuff you feel
    the kind of stuff you reach for when you fall

    kinda like perl, huh? forgive the digression, the epiphany you describe is one of the things i like about programming in general. i just love it when a plan comes together.

Re: Code that feels good
by dhammaBum (Acolyte) on Aug 27, 2001 at 09:18 UTC
    Yeah, just this process has happened to me a few times recently - not that I code that much. Part of my problem has been jumping in with a mish-mash of ideas and trying to stich them up while coding.

    One would hope that the top-down programming discipline would short-cut this, at least a little. By this I mean working out higher-level logic after considering as many of the aspects of the problem as is feasible. Then actually testing this logic as if it were a program with realistic data.

    But I have to agree, that breath of simplicity does seem to be a result of after-the-fact fiddling.