What happens if I get to page 50?

I used to have a writing professor at college who gave me some of my most important insights into the creative process, producing fiction, and other such matters. At that time, I was writing a lot of short stories (I hope to one day resurrect some of them for posting on this blog!), but I always had trouble finishing them, coming up with endings.

Turns out, that’s actually due to a quirk in my personality, which I am still trying to learn to embrace.. and a lot of what I’m learning in this area applies to my career as a software developer.

The professor had some great advice for me, when I asked for a suggestion of how I could tell when a story was “done”:

If you get to page 50 of your story, but you aren’t done, then you must be writing a novel!

Wow – that’s totally true. Inarguable.

Creativity and Guidelines for Software Developers

Here’s a question that may apply when working on a software development project:

What if I “get to page 50”, but my documentation is still in flux, and I can’t figure out what to deploy?

It’s a software development project which has gone off the tracks, and is now meandering, not sure whether it should be on a “road”, or a “track”, or a “river”, or just “flying out someone’s window”.

When I first started out as a software developer, I read every book I could get my hands on. I probably got WAY more advice than was actually useful. It was a few years before I started to sort things out and realize that software is divided up into the following types:

  • For internal business use, front-facing application.
  • For internal business use, as a component of other applications.
  • Software which is going to be released or sold to the public.
  • One-off projects (which could be either for personal use, or for the guy downstairs who just needs a report pulled from a few systems).

And it took a good bit longer before I realized that the books about programming which I was reading, were all only applicable to a SINGLE type among these various types of software product.

For example, most of what I was reading would have been most useful to me if I were building components all day. But I wasn’t. So I learned how to over-engineer my one-off projects.

A few years into it, I “got to page 50”, and I realized that I was writing a novel, but that’s not what I was supposed to write – not at all! Even today, I find that the writing I read about programming very rarely makes a distinction regarding the type of software / programmer which is the intended audience.

Today, I figure I could make a killing by just writing a book which catalogs all the great writing and advice which is out there, with indications of what type of project or product it applies to..