"Each problem that I solved became a rule which served afterwards to solve other problems."
       -- Rene Descartes, Discours de la Methode (from Rationality Quotes 10)

this is similar to what i do as i write code. when i started out writing lotusscript, i popped everything into the Initialize event. hey, it worked, right? it wasn't exactly maintainable, but i got through somehow.

then later i started breaking things out into functions and subs. hey, pretty cool for a guy who didn't study this in college. eventually i started writing OO constructs, and that was when things started changing. the idea of reusability became more palpable somehow.

i realized i'd been solving the same problems over and over again - badly: i got the same run time errors, pretty consistently from certain operations. for example, i must have gotten "object variable not set" about a zillion times, from not properly checking the objects when i was getting a text value. this one little function, which isn't part of an OO construct but exists in my Utils script lib, has saved me many hours of idiotic debugging:

Sub getItemText ( doc As notesdocument, itemname As String, strval As String )
       Dim item As NotesItem
       If doc Is Nothing Then
               strval = ""
               Exit Sub
       End If
       If Not doc.HasItem( itemname ) Then
               strval = ""
               Exit Sub
       End If
       Set item = doc.GetFirstItem( itemname )
       strval = item.Text
End Sub

sometimes it's the simple things, ya know?

in terms of the Descartes quote you could look at this code one of two ways - you could say, i don't have to ever write that code again, because i've solved that problem, and therefore i don't have to think about it. and so, in one sense there is no "rule" i'm actively thinking about. the point is that i don't have to solve that problem again!

but whenever i consume this code, i am in fact implicity following the rules laid out in the code itself (check to make sure that the objects exist before trying to use them), and i'm following another rule: don't keep on rewriting the same broken shite over and over again. put robust code (that doesn't break when the item, or even the document, happens to not exist) in one place. you are done. because you have bigger fish to fry.

so what happens is, i am building little stepping stones, little foundational bricks, that i can build truly complex applications on top of, without getting bogged down in structurally obfuscated complexity, and with less run time errors too.

has it ever struck you that the tools and materials in hardware stores are like little programs that people have built, that have "real world" properties and methods? screwdrivers, hammers, nuts and bolts, drywall, plywood and so on are all designed to standard specifications. everyone knows how to use those things, creatively, in a standard way. and you can take those materials and tools and build things like houses and office buildings with them! without those tools, you've got nothing to start with. you've got to invent it all from scratch.

even in an environment like Notes Designer, where so many things are already provided for you, you still have to create your own toolbox. or you have to become intimately familiar with someone else's (ext, prototype, dojo, etc). you have to discover the solutions that become the rules that you follow. because the rules allow you to create applications that are less prone to errors, are easier to maintain, and achieve understandable complexity early (i.e. achieve business goals) in the design cycle. this, it seems to me, is the path of the artisan.