Comparing Crafts

I’m going to take a brief diversion from my series on Demo Showcase to discuss a parallel I found this weekend between developing software, and writing. As you can probably tell by the length of the entries on this site, that I love to write. I love it so much, that I have a web site completely devoted to my writing at www.joebeernink.com. I write novels. I write short stories. Hell, I like writing specs. But I also like to code. I like to dig into new technology. I like to solve hard problems. I thrive when faced with tough challenges. But back to the writing.

This weekend, I attended the Pacific Northwest Writer’s Association Conference new Seattle. This is a four day writer’s version of NerdDinner. Instead of hanging with Scott Guthrie and Scott Hanselman, I got to hang with Terry Brooks, Robert Dugoni, Will North, Joseph Finder, Richelle Mead, Caitlin Kittredge, and a thousand other writers and aspiring writers.

People talk often about the craft of writing software, and I think that has obvious connections to the craft of writing. Writing crappy software is easy. Writing crappy stories is easy. Writing good software takes education, practice, persistence, self discipline, structure and patterns, research. Writing is exactly the same.

You need to be skilled at the language you are writing, and know the vocabulary. Writing a great novel doesn’t happen on the first try. Just because you have spoken English your whole life doesn’t mean that a good novel will result when you put pen to paper, or fingers to the keyboard.

You have to keep writing, even when people give you negative feedback. If we all stopped writing code every time a user found a bug, or the compilation failed, or took it personally, we’d never get better at it.

You need self discipline to always strive to learn, to read that dull book on ASP.NET MVC, even though you think you already know ASP.NET. I mean, nothing will ever make VB 6 outdated… right?

You need to understand the structure of a good story, and the structure of a good piece of software. There are patterns and practices that have evolved, and yes, you may find another way to do something, and it doesn’t mean you are wrong, but there are some things that are just not worth reinventing. At least know what options are out there, and use the power that’s in them until you find a need to diverge. This isn’t meant to stifle progress. It simply means that not every piece of software is going to be a unique and brilliant creation. We get paid to turn out software that works. Novelists get paid to turn out writing that sells. If you don’t want anyone to read your book or use your software, go crazy.

Research the stuff that interests you. Read code from similar programs. Novelists need to read other authors from within their genres, not to copy, but to learn. Know what that code does before you copy and paste. Understand why it works. Find the patterns in plots of great novels. What tools does the author use?

None of these are spectacular revelations, or at least they shouldn’t be. But something hit me, a parallel between my career as a writer and my career as a software developer.

I started programming computers on a Commodore 64 in 1982-83. I was 11 I think. Actually, I had programmed on a PET CBM prior to that, but the C-64 really got me started. I took programming courses in high school and college, did an internship in college, and spent the years 1994-2007 working in the field taking a few courses here and there, picking up a book when I needed to, but never really taking charge of my career. But at the end of 2007, I realized my career was at a dead end. I had let my technical knowledge stagnate, and was blaming everyone else for my lack of opportunities. I made the leap from IT department at a large airline to a small consulting firm at the start of 2008, and vowed that I would spend a minimum of 3 months reading everything I could, as fast as I could, about the technology I was going to be working in, to get better, I wasn’t going to take courses, or expect someone to teach me.

I read on the train. I read at night until I couldn’t keep my eyes open. I read on the weekends. At the end of the three months, I realized that I had learned a lot, and had a lot more to learn. I filled up my wish list on Amazon with all books on every area of software development that I wanted to learn. I got a subscription to MSDN Magazine. I read the articles, instead of skimming them. I added dozens of blogs to my RSS feed. I read whatever I could there. I gradually brought my skills up to the point where I felt that I could talk intelligently about software development again.

Similarly, I started writing stories in grade school. I wrote them freehand until I had a Quick-Brown-Fox word processor for my C-64. Then I typed them out and printed them on my MPS 801 printer. I took a lot of English classes in high school. My schedule was too full to take classes in college, but I did write my first novel while there. I loved writing for the escape it provided from the pressure of my classes. I wrote a bit after college, but it was in fits and starts. At one point, I stopped altogether, until August of 2008. That’s when I got the laptop I am typing this on (a Toshiba U405-S2854 which I love).

I started writing a new novel on August 8th, and finished the first draft on January 1, 2009. But I missed something. I thought that writing was something I could just jump back into, and do without reading technical books on how to. I didn’t bother to figure out what genre I was working in. That has huge implications on what rules you need to follow. I didn’t bother to read other authors in my genre to see what was working. I didn’t practice my craft and look for feedback. I just assumed I was good, and smart, and that this writing thing wasn’t that hard.

This weekend was an eye opener for me. The successful authors study their craft. They practice, sometimes for more than a decade, before they get something published. They treat their hobby like a business. They are the CEO’s of their own corporation. They get feedback from their customers. They manage their brand. They work their asses off. You could see those in the audience that weren’t prepared to do that. They blamed agents and editors for their work not getting sold, or argued with the agents and editors about the quality of their work. For a new writer, that’s like arguing with the C# compiler that it should know what you meant, not what you entered. The compiler will be right 99.9999% of the time. If you go to three different machines, and the problem is repeatable each time, it’s your problem. If three agents tell you your writing sucks, it’s your problem. Fix it.

So why am I writing about this on a tech blog? It’s because it took me 13 years of my software career to realized that no one is going to make me a better coder / architect but me. It took me a year of writing, and a brutal slam from an agent to realize that I need to work as hard at writing as I did at improving my tech skills. And that takes time, and a plan. I filled up my shopping cart at Amazon last night with great books on writing, and expect to spend the time between now and Christmas reading those, and using the lessons I learn from them to improve my writing.

Where does that put my technical career? Right where it was. I just need to do both. To find more hours in the day. To work smarter. To learn the lessons I’ve been talking about in all these other blog entries so that on the next project, I don’t spend days regression testing manually. To do it right the first time. There’s just so much to do and learn out there, why screw around reinventing the wheel? Hopefully, after reading these entries, I help you to save time you could better use to bring your skills up to date, to create that vicious, incredible cycle of learning and doing things better and faster to give you the success and the time to do the other things in you life that mean something to you.

Good luck!