I’ve made half hearted attempts at writing before (not counting songs), but they didn’t last. At first, I failed because I forgot the first rule: write what you know. I tried to show everyone how smart I was with florid prose, but there was no there there. I threw (almost) everything away.
“All you have to do is write one true sentence. Write the truest sentence that you know.” – Ernest Hemingway
With the nonchalance of a true master, Hemingway makes it sound easy. Oh, one true sentence, is that all? He fails to mention your sentence also probably needs novelty. We can all think up profound truths real easy, but those are called platitudes. I failed again: I wrote things that were true, but not new. I bored myself — why would anyone else read?
I do technical work for a living, and people often encouraged me to do technical writing. That offered plenty of opportunities for newness, but I didn’t know how to talk about that subject either. The weight of all the technical writers’ combined knowledge overwhelmed me, and I felt I couldn’t compete.
What changed?
Last summer, I co-taught the first Web Development Immersive course here in Austin for General Assembly. Twenty students from all walks of life learned what they needed for a career in web development in an intense twelve weeks. I’m not gonna lie to you, like any other bootcamp, it was hard. There was crying.
Everybody learned like crazy though. I learned so much teaching that course, I won’t even try to list all the things, but the writing process began when I realized that a lot of the students didn’t have a good mental model for debugging. I needed something for pure beginners who didn’t even know where to start, but googling returned only guides for how to use specific technologies.
The tech I work with is on the bleeding edge, and when google searches on a subject start coming back with few results, I feel like a sailor from a thousand years ago, having gone off the edge of the map to where there be dragons. When I couldn’t find a 101 for debugging, I knew I had to write one (I’ll share it as my next post).
##My Path
My mental model of debugging began in high school, doing auto maintenance in my parents’ garage in rural New Hampshire. In rural New Hampshire, you have to have a car so you can get money, so you can get a car, so you can get out of rural New Hampshire. I learned how to deductively exclude possibilities, because I couldn’t afford to mistakenly replace a working part. I learned how to isolate intermittents, because if my car wasn’t reliable, I might lose my job.
I had to get out of New Hampshire so I could go explore the world of music, but I found more debugging there: some literal, like diagnosing malfunctioning equipment, to more subtle and abstract forms, like identifying mental obstacles that prevented me from progressing. But those, as they say, are stories for another time.
##This is what I know:
I write about technical ideas in a layman’s voice. The ideas come from programming, music, science, auto repair, doesn’t matter. What does matter is that they resound with many different kinds of folks. I have been fortunate to have some great mentors help me along my path, and I want to give back by sharing anything I’ve learned that might be interesting.
Thank you for reading. I hope you enjoy it.