Log in

No account? Create an account
Lindsey Kuper [entries|archive|friends|userinfo]
Lindsey Kuper

[ website | composition.al ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

/ [Feb. 28th, 2008|03:10 pm]
Lindsey Kuper

There's a sentence near the beginning of TeX for the Beginner by Wynter Snow1 which has stuck with me for years. I don't have the book handy, but it goes something like this:

There are two kinds of bugs: typos and opportunities to learn.

There's a problem I've been trying to diagnose for the past couple of days. When I was becoming discouraged about it earlier today, I thought of that quotation and immediately felt better. "I'm so deep into this at this point that it couldn't possibly be a typo, so at least I'm learning! And I've been working on it so long, I must be learning a whole lot! Awesome." I attacked the problem with renewed vigor.

Just now, I finally ferreted out and fixed the bug. Guess what it was?

An extra '/' at the beginning of an XPath expression. Yeah. A typo.

So. Today I learned that sometimes, things that appear to be learning opportunities are, in fact, not.2

  1. Actually her name, and the reason I picked up the book in the first place.
  2. In fact, this might be the central dilemma of my professional life.

[User Picture]From: stereotype441
2008-02-29 12:19 am (UTC)
Here's a quote from a great programming book I once read, also paraphrased (I think it came from either Debugging the Development Process or Writing Solid Code):

Whenever you find a bug in your code, you should ask yourself two questions: (1) How could I have easily (or automatically) detected this bug? (2) How could I have prevented this bug from happening in the first place?

In my opinion, anything that causes you to spend a lot time debugging is an opportunity to learn, even if it turns out to be just a typo. You have to ask yourself, "Why did a simple typo cause me to lose so much time? How can I change things so that typos don't cost me so much in the future?"

I can think of a bunch of possible lessons in your situation (of course, none of these lessons might apply in your particular case):
- XPath is full of traps and it's easy for an innocent-looking typo to spoil a query.
- People are so used to reading "\\" as "\" (because of the use of backslashes in escape sequences) that making "//" have a different meaning from "/" was a poor design choice on the part of the XPath folks*.
- I need to wrap my XPath expressions in a helper function that sanity-checks them.
- I need to wrap my XPath queries in a helper function that sanity-checks their results.
- Rather than code most of my XPath expressions by hand I should have a function that creates them according to a certain template, so that I'm less likely to make mistakes.

*In fact, I would argue that the very existence of XPath is a classic case of the primitive obsession code smell.
(Reply) (Thread)
[User Picture]From: lindseykuper
2008-02-29 01:14 am (UTC)


What are you, some kind of experienced professional software engineer or something?
(Reply) (Parent) (Thread)
[User Picture]From: oniugnip
2008-02-29 03:21 am (UTC)

Re: hey-o.

*laughing out loud!*

So many learning opportunities. It's interesting how much of being effective is learning where to direct attention, what to make unconscious, and what to be more conscious of...

And there are definite non-typo learning opportunities coming 'round the bend in about six months, yeah? :)

(Paul, I like that last option a lot...)
(Reply) (Parent) (Thread)