How to Be a Better Writer Through Blogging

As one of my colleagues is fond of saying “practice doesn’t make perfect, it only makes permanent.” His point is, it doesn’t do you much good if you keep practicing the wrong thing. So, when blogging, pay attention to style as much as substance, even though it’s “only a blog.”

• Be eager for feedback and treasure any that you get.
• Give yourself feedback. Simply go back and re-read what you wrote (the next day, and again later). Is what you wrote still as clear now as you thought it was when you wrote it? If not, figure out what you did wrong.
• Proofread three times before clicking Post: once for content and clarity (how many times have you forgotten that ever so important “not”?), once for rhythm and style (word choice, asking questions or issuing commands instead of just making statements, etc.), and finally one last time for spelling and grammar.
• Buy a style guide and use it. The Skunk and White you got in college will do, although one made specifically for journalists is a lot better for blogging purposes. (Mine’s the Washington Post version. I got it for $2 in a library liquidation fundraiser. I understand that the Associated Press puts out a good one.)
• Already have a style guide? Supplement it with a thesaurus – a real Roget-style 2-parter, not one of those silly alphabetical-only compromises (of course, that would certainly be better than nothing).
• Take advantage of spell check and grammar check tools and don’t be too quick to ignore the suggestions they give you. Tip: a grammar error is often actually a spelling error in disguise because the misspelled word looks like another word (“fell”/“feel,” “fiend”/“friend”, “it’s”/”its”).

Most importantly have fun with your blog. Write about the things that tickle your fancy. Write about your hobbies. Write about the “good” parts of your job. Write about the fun stuff that your friends, colleagues, customers and vendors are up to. The more interesting the topic, the more you’ll enjoy investing your time on it, don’t you think?

Keeping Crib Notes

• What’s the regular expression pattern for validating an e-mail address?
  
• What are the command-line switches for configuring a Windows Explorer shortcut?
  
• What are the 10 best opening hands in Texas Hold’em poker?
  

I can answer those questions in 10 seconds flat (assuming my laptop is booted up), because I maintain a series of “crib note” documents with just such information. (Currently, I use one Word doc per subject, but I’m thinking of moving it all to a personal wiki). I tend to do everything on the computer, but I know other people who handwrite such notes in an engineering notebook or keep a loose-leaf binder. Pick your poison.

The trick with any of these is figuring out what’s worthy of jotting down, and what’s not. Here are some of my criteria:

• How hard was it to find the information? How hard will it be to find it again?
  
• What’s the likelihood that I’ll need this information again? Is this already the second or third time that I’ve needed it?
  
• Is this something I’m trying to become an expert on? Will writing it down help to reinforce the lesson, even if I never need to consult the note again? (But then I’ll have the note as a backup, just in case.)
  

My notes are currently divided into 18 folders: Self Improvement, Business, Office, Home Improvement, Hardware, Reference, Hobbies, Programming (in general), plus ten specific programming topics like Java and XML.

Foolish Anagrams

Several years ago, my office mate, Jeff Davidson, and I got on a word-puzzle kick and we discovered an anagram engine on the web (now located at http://wordsmith.org/anagram). April 1st was coming up and we decided it would be fun to replace the nameplate of everyone in the office (about 35 people at the time) with an anagram of their name for the day -- a nice, clean practical joke. It took a little doing, even with help from the engine. For some people we had to try different variations like using Dave instead of David, including their middle initial, and/or adding a title like Mr., and so forth.

JARGON SLICE
Craig L. Jones

SONIC GERM JAR
Mr. Craig Jones

Then, it was just a matter of printing them up on card stock (we used something like 72pt type for the anagram with the original name centered underneath it in 18pt) and swapping them out for the real nameplates the night before.

INVADE MY FJORD, SERF?!?
Mr. Jeffrey Davidson

Of course, we stashed the real nameplates in Walter’s office along with other incriminating evidence. (Walter, you see, was even more famous for wordplay than the two of us.)

LET WAR RISE!
Walter Reis

Well, the joke was on us, because nobody saw them. One of the first people to arrive in the office that morning was a V.P. with a bug up his butt who didn’t think the anagrams were funny. (I’m sure he didn’t even recognize them for what they were.) He promptly tore them all down and put the real nameplates back up, mumbling about the company expecting visitors in the office that day (not true). Eventually, someone rescued the torn-down anagrams out of the trash and Jeff and I saw a number of them taped to people’s monitors by the end of the day. Oh, well.

If you try this yourself, you’re bound to get a better reception than we did. If, in your efforts, you come up with any real gems, please post a comment here. I can always use a good laugh.

I Blog, Therefore I Am Better

I’m not sure if writing a blog has been good for my soul, but I am sure it’s been good for my career. It gets me thinking, and asking questions. It gets me to practice my writing. Best of all, whatever I write about "sticks" better. “See one, do one, teach one.” Isn’t that the slogan that Med students live by?

"Head First" Book Sometimes Makes My Head Hurt

I’m helping out with a study group for "Head First Design Patterns," which just finished chapter 6. On the whole, it’s a pretty good introduction to software design patterns – way more accessible than the seminal work by the Gang of Four; however, the examples sometimes make my head hurt. I can’t imagine what they’re doing to the heads of the beginners in the group. Coming up with decent examples is the hardest thing to do in expository writing, and I certainly give the authors an E for effort in creativity, but I wish they had been a little less concerned with making their examples "hip" and a little more concerned with making them appropriate.

To wit, the whole pizza store analogy in chapter 4 (to illustrate factory method and abstract factory) is flawed. For one thing, that’s just not the way you’d model a pizza business in any actual software that I can imagine. For another, the differences between a New York pizza factory and a Chicago pizza factory are too subtle/trivial to make for an effective illustration of why you would need to subclass anything (much less use a factory to manage the subclasses). A much better example, as everyone in my group agreed, would have been an application that needs to offer up a consistent set of functionality to users who are accessing it in wildly different ways: one’s in a web browser on a desktop, another is running a cell phone app, another is using a touch-tone phone, and yet another is using a voice-activated headset. All the client code knows is that, for example, it needs to ask a multiple-choice question and obtain the answer. It’s up to an abstract factory to provide the client with a set of classes that can do that, in the context of the selected user-interface, in whatever way is necessary.

To a lesser degree, the Starbucks coffee example at the beginning of the book suffers from the same too-hip-to-be-effective syndrome, although I do think that the remote-control example for the Command pattern in chapter six is dead on.

For any novice who is reading this book without the benefit of a study group, I highly suggest that you find at least one other programmer who is experienced in design patterns to explain why/if/how the examples are lacking.

Wax On, Wax Off – Red Bar, Green Bar

TDD has become as automatic for me as breathing. It’s a beautiful thing when you get to start a new project from scratch and can write every line of code test-first. These days, however, I’m working on a legacy app with very little in the way of unit tests, and it feels as if I’m working at 5,000 meters above sea level and struggling for every breath of rarified atmosphere.

So I can only imagine how it seems to the rest of my team, for whom automated unit testing is a new concept. The level of drudgery involved in retrofitting a legacy app with a test harness rivals the chore of waxing Mr. Miyagi’s deck. All I can tell my teammates is that it’s good practice. Soon, writing unit tests becomes a habit, and then, eventually, it becomes pure instinct. Attack from the right? Wax On! Attack from the left? Wax Off! Add a new feature? HTTP-Unit! Change a business rule? JUnit! Keep it up, and that black belt will arrive in no time.

Copying SQL Records within the Same Table

I discovered a neat trick for copying a record, or set of records, within the same SQL table today. For example, say you have 20 employees listed in department A, and you want to clone all 20 records to also be listed under department B.

You may or may know that this can be done with a single INSERT INTO statement if you use an embedded SELECT statement in place of the VALUES clause. The hard part is that you cannot just use SELECT * FROM table WHERE ... becuase the * would pick up the key field (e.g. DepartmentID) along with all the rest. So, you have to list every field in the table by hand, except DepartmentID. You would specify the new value as a constant ("B") instead.

The "trick" is that you can probably find a tool that will generate the INSERT and SELECT statements for you. In my case, I'm using the Query Analyzer that comes with Microsoft SQL. In the explorer pane, navigate to the table. First, right-click and choose the option to generate an INSERT script and send it to the clipboard. Paste it into your favorite editor. Next, right-click and choose the option to generate a SELECT script and send it to the clipboard. When you paste this snippet into the editor, do it so that it replaces the VALUES... part of the INSERT statement. Finally, change the field name of the key field in the SELECT statement to the appropriate constant.

The Cobbler's Children Have No Shoes

This blog is back. It's been offline for far too long -- a case of me being so busy working on software projects for other people that I haven't been able to keep my own stuff going. Anywho... Things are starting to settle down, so you can look forward to more of my endearing, but not necessarily enduring, wisdom to come.