I am slowly but surely nerdifying my girlfriend.

When I met her she played "The Sims". I introduced her to Civilization
3. From there to an RPG / Adventure game. Next step.. Dungeons and
Dragons :-D

And since we are on the subject of Java & relationships :)

*HOW to improve your sex-appeal with a good Java program* :

First things first : get in super.Shape. Next: all your URLs should
be created with protocol "female", same with URI schemes. As a
consequence, you'll notice that your GeneralPath will lead you into
Area(s) populated heavily with public class Women.

Secondly, as the Window of opportunity tends to be very narrow,
don't lose Focus! Make sure that a lot of instances of public class
Woman have FocusTraversalPolicy set on you.

Thirdly, implement as much Listeners as possible (public class
Women like being listened to). Then you have to establish a
Connection (some PreparedStatement might come in handy),
followed by Identity. Remember that Naming.lookup() is a
great ice breaker.

After a while, you have to broaden the IdentityScope. Visit some
KeyFactory and then exchange your public Keys. Don't think you're
home free, though. GC also comes with the package. You'll also
have to learn to be a good Observer. Your Observable will like
that very much.

Further more, the trick is to use a long, Long or Big* member
(field). Put it to work in an inner Socket, preferably doing it safely
(SSLSocket). Catch all the Exceptions in all the OutputStream(s)
unless you explicitly want child Processes. Moreover, don't rely on
your average BasicStroke, you have to come up with some versatile
method(s). Extending the built-in Socket(s) with something like
Suckit(s) might also impress some public class Woman, but some
don't like using MulticastSocket(s). Speaking of which, allways
check the .getPreferred*() beforehand. Otherwise you might have
to deal with nasty Throwables, like IllegalAccessError. Also take
into account that NoSuchMethodError means NoSuchMethodError
(same for NoSuchFieldError and the analogous Exceptions).  

Having dealt with all that, make sure that you close all the necessary
ports on your firewall, because InterruptedExceptions tend to be very
destructive (plus your Reference will become a SoftReference (i.e. your
RoundingMode will switch from UP to DOWN) for an indefinite period
of time).

Sooner or later you'll have to realize that the best you can do is to
make your instance of public class Woman final and static. It's not
unusual that in the process you also make it private, though protected
might also work in some cases. Of course, you'd have to say goodbye
to Swing for as long as you both shall live.

Well, my husband and I both work in technical fields, but he does
assembler-level firmware, and I'm currently doing end user Java apps.

We each can understand enough of what the other's doing to sympathize,
but not to write each other's code.

. . . . . . .

I find you a mite more competitive in your relationships than in mine

--
LTP

I largely agree.  There have been times when I've cranked out code that fast or
faster (I'm pretty quick when I'm on a roll), but normally I'd say that if you
are in that position then there's a good chance that you are missing a chance
to abstract and/or automate.  If the code doesn't need thinking about to
write[*], then that is at least a fairly strong hint that you might be better
off telling the computer to write it for you, or that there is some other level
of abstraction that you are missing.

([*]Which should be a fairly rare situation, for precisely the reason given
above.)

Of course, that does depend on the quality of the tools you have available for
automation and abstraction.  In inexpressive languages like C or Java, there
aren't many tools "in the box", so you are more likely to find yourself in a
position where it is both possible and appropriate to crank out code "quickly"
than if you were using, say, Lisp.

   -- chris

The only time I've generated (working...) code at that
rate was writing header parsers for image formats.

Somce (old) image formats are well documented, but quite
messy.

So you generate quite a lot of simple code,
that is't quite... simple enough to factor out.

This makes for a high rate of code-line generation.

In all other cases, yeah, 100-200 lines a day of debugged, working,
maintainable code is about the going rate.

This always surprises "bedroom geniuses"

    BugBear

   Lines is kind of an iffy metric anyway. Maybe the OP puts the curly
braces on seperate lines, and maybe you don't. JavaDocs add a lot of "easy
lines" too ("/**" counts as a line, right?).

   - Oliver

This boneheaded post could almost be considered on-topic for the thread...

   -- chris

We are talking about programmer sexual fantasies not job opportunities.
Also your advertisement breaks any number of equal opportunities laws, and as
for your English skills , well!!