It occurred to me this morning that writing about what was wrong with my 6502 machine language article from the early 1990s might be useful. Or maybe that was just whatever the dentist was injecting into the roof of my mouth talking, but I’m going with it.
Should I cut myself some slack on account of my age at the time? Sure. But teenage Dave would have welcomed the critique of mid-30s Dave, if either could find Dr. Emmit Brown’s DeLorean.
The first problem was inexperience, both on the part of the author and the editor. I was 16 or 17. I’d written for my school newspaper and the local Commodore users group newsletter and I’d even published in a couple of magazines by this point, but I was still pretty green. As for the editor, his editing career lasted about six issues before the publication folded entirely, and I don’t think he had any prior experience to speak of. Green as I was when I wrote it, I was probably better qualified to edit him than the other way around.
The first problem that jumps out at me is the comma/semicolon. I suspect he did a global find/replace and changed all my semicolons to commas, because I’ve known since at least the fifth grade how to use a semicolon. I was properly using semicolons when my peers were still struggling with when to use capital letters. If I could ever find the original manuscript, it would be interesting to see how many semicolons were actually in there. I had a tendency to overuse them.
And that’s another problem. The average sentence length in that article is too long. How long is too long? I dunno. I knew I was doing OK when my editors in journalism school quit yelling at me about that. All I know is that article made me start hearing those voices again.
But, generally speaking, I used too many semicolons and not enough periods in my youth. Frankly I used too many commas and not enough periods, too. Changing thought mid-sentence is something that should happen rarely. Usually, it’s better to end the sentence, start a new one, then pick up the train of thought again with a new sentence.
And speaking of trains of thought, I really wish I’d broken the article into sections and used subheadings for each general principle. It wouldn’t have made it any less readable, and would have made it much easier to refer back to.
I also overused parenthesis. Byron Scott, one of my favorite journalism professors, called parenthesis “walls in the middle of your sentence.” They’re fine to use to explain an acronym, for a citation, and a one- or two-word note. But long parenthetical remarks are better set off by dashes–like this–instead. Then your eyes can keep moving. Or you can just make them into standalone sentences.
And finally, there are way too many cliches in it. Here’s my worst offense:
The “bag of tricks” possessed by the 6502 family of processors, including the 8502 found in the C-128 is somewhat limited, but its contents are often rather unique and effective. Before I start presenting tricks, let me give you a warning. During the actual coding process, it is best to ignore the majority of these tricks and program traditionally, for the purposes of debugging. Only after you are satisfied with the integrity of your code should you “open the bag,” so to speak.
Something like this is clearer and more concise:
The 6502 family of processors has somewhat limited options for optimizing code. The options it does have are effective, but can be unclear. During the actual coding process, don’t get too fancy. Code traditionally, then test and debug. Don’t start trying to optimize it until you are satisfied your code works as intended.
I’d almost rather go to the dentist than read Eugene Petersen, and the reason is because he plants a cliche in every single sentence. Some people seem to think that cliches make a sentence punchier, or add flair. It doesn’t. And some cliches don’t age well, so they end up dating your work, like peppering your writing with words like “groovy” or “swell” would. I guess the advice in my offending paragraph holds. Don’t try to get fancy. Just write what you mean, and given the choice between a tired expression and your own words, go with your own words.
And that’s probably more than enough admonishment to the teenaged version of myself.
David Farquhar is a computer security professional, entrepreneur, and author. He started his career as a part-time computer technician in 1994, worked his way up to system administrator by 1997, and has specialized in vulnerability management since 2013. He invests in real estate on the side and his hobbies include O gauge trains, baseball cards, and retro computers and video games. A University of Missouri graduate, he holds CISSP and Security+ certifications. He lives in St. Louis with his family.