Rely on the Wisdom of Friends and Strangers - Ask for Help!

[originally published as part of my ODTUG Confessions of a Quick and Dirty Programmer column]

Surely the best way to write a ton of quick and dirty code, and never, ever stop writing such code, is to be firmly convinced that you know all there is to know about something/anything, and stop learning from others.

Consider me - and PL/SQL.

There seems to be an impression among PL/SQL developers "out there" that I know everything there is to know about the PL/SQL language and (even more amazing) Oracle technology more generally.

Ha, I say, ha!

Certainly, I know more about this language than almost every other human being on the planet. Yet I am reminded, in just about every training and presentation I do, of how much I don't know and how much I can learn from others. For, when it comes to programming, the gap between "book knowledge" and "experience knowledge" is vast. It's one thing to know about syntax and features; it is quite another thing to know how to apply those features.

Accepting the limitations of experience, though, is just one part of the escape from smug belief in one's own "know-it-all-ness." Another key ingredient to developing a deep humility towards one's specialty is visibility. The more one's peers see, read and try to use your code, the more weaknesses are exposed in that code and your expertise.

Of late, the most intense and, well, challenging reminder of my limitations is the PL/SQL Challenge.

I decided back in 2010 to build a database of quiz questions on PL/SQL, and then create a website around that database to offer my daily quiz. Gosh, that doesn't sound so difficult, does it? And certainly the easiest part of that would be writing the quizzes. Surely I know how to do that well!
Or not, as the case may be.

Well, I wrote over 600 questions, and then I worked with my friends at then-Sumneva (Dimitri Gielis, John Scott and Paul Broughton) to design and build the website. I was also assisted beyond easy description by Finn Ellebaek Nielsen, one of the smartest and most knowledgeable Oracle technologists I have ever met.

We launched the site in April 2010 and since then I have been taught by PL/SQL Challenge players just how difficult it is to write unambiguous and 100% accurate quizzes. All too often, players have delved into the nooks and crannies around my questions and answers -  and discovered outright errors; exceptions to the "rule" (that I state or assume in my question); features or behavior unknown to me; assumptions I have been making about PL/SQL that are wrong.

Some players have commented on how addictive the PL/SQL Challenge - I sometimes wonder if they are not getting addicting to proving me fallible!

This widespread laser-like focus on what I am doing has had a noticeable impact. Since I could not afford to allow mistakes to continue to creep into the quiz process, I instituted changes in process as follows:

1. Complete a checklist for every quiz. I no longer have to remember all the key steps in my head (such as "Never use words like never and always. Absolutes are very dangerous.").

2. Generate a verification script from the question and choices, to validate all code examples and claims made in the answers. After all, if it's not tested, you don't know for sure that it is correct.

3. Have at least one PL/SQL developer (not anadmin and not someone who plays the daily quiz) review each quiz.

Does that sound like common sense? Absolutely. Does that sound exactly like what we should all be doing with our application code? Absolutely.

So in this case, I not only learned directly from others (players in the PL/SQL Challenge), but I also learned from this "other" scenario (publishing quizzes). That is, the steps required to ensure high quality quizzes are (some of) the same steps I should be taking to ensure high quality application code.

Learn From Others Even If They Are Not Programmers

Programmers are like any other defined group of human beings. We have our own language (mostly acryonyms), our own diet (Diet Coke and chips), our own forms of entertainment ("Wow, what a cool algorithm!"). That's all well and good, as long as we don't develop the attitude that we have nothing to learn from non-programmers. This attitude of "exceptionalism" (we are different - with an unspoken implication of  "better" - than others; they have nothing to teach us) is both arrogant and self-defeating.

Last year, we decided to go "off the grid" by installing a photovoltaic array of solar panels on the roof of our house, and attaching that array to a whole bunch of batteries. I got a very reasonable quote from a person who claimed to know what he was doing. And he did it - he installed 12 180kw panels and 24 batteries, hooked it all together, flipped the switch - and we had electricity from the sun. Here's a picture of the inside of the PV "shed" in which the batteries were located:

So we were happy. We had power from the sun. A few weeks later, another electrician (Noel) came to the house to install some light fixtures. He asked to see what the first electrician (Jose) had done, since he also does this work.

He went into the PV shed - and came out angry. He felt that Jose had done some very sloppy and dangerous work. He said that the installation did not follow code, and he pointed out that this fuse:

said on it "Audiophone." It was a fuse for a car stereo system, definitely not the kind of fuse needed to handle multiple kilowatts of energy. I was, to say the least, dismayed. I thought about demanding that Jose fix his earlier work, but realized that Jose clearly didn't know what he was doing. Why would I expect to be able to fix the problem he introduced?

[Hmmm. Now there's an interesting thought to apply to fixing bugs in software!]

Instead, I asked Noel to refactor the existing implementation. And when he was done, the wall of the PV shed looked like this:

Notice how neat and clean it is; all the electrical wires and now enclosed, so they cannot be easily damaged. And everything has a label - in fact, when I open the door of the gray box, I see:

It wasn't until several weeks after Noel had finished his work that I realized that:

1. Jose's approach was a classic "quick and dirty" job that was cheap but impossible to maintain and likely to break or cause problems.

2. Noel's approach represented a "best practices" style in programming: encapsulate or hide the details of the implementation; document the architecture and key features of the system so that everyone (including the original "author") can come back later and understand what is going on.

How delightful to learn that the same principles that drive best practice programming also apply to electrical work! Once you can see this (and surely those same principles apply to many other endeavors), your eyes will be open to so many more opportunities for learning how to improve your code.

You Can't Learn If You Don't Ask

When you are stuck trying to sort out a bug, when you are not sure about how to solve a problem or implement an algorithm, when you wonder if there might be a new feature of Oracle that could help you, ask someone for advice or help.

It is much, much harder to learn if you don't ask for help, if you don't actively seek learning opportunities.

If you are one of those unfortunate programmers who mostly codes in isolation (a team of one, or a team of more than one, but with very little interaction), you might not have someone to turn to for help.

In that case, I suggest that when you are stuck on a problem, write yourself an email, explaining the problem and what you see as possible solutions. Simply getting that information out of your head will change the way you look at it and make it easier to find a solution.

The bottom line, though, is that no matter how much we know, or think we know, we can always learn more and different from others. Leverage that fact or you will be stuck in a rather deep rut constructed with your own limitations.