At my last and only full-time job, I spent most of the last 10 years of 16 doing software design and development. The funny thing is I have a degree in English Literature and never once touched a computer after that horrible DOS-Basic class in 7th grade, where the blinking cursor on a black background mocked me, until I got a computer as an adult, well-after graduation. At work we had only terminals so we could enter data into the mainframe. Gradually, in the late 90's we got PC's and I lucked into learning Lotus and DBase IV, all on an OS/2 platform (sorry to nerd out just a little - I know someone out there will sigh with a sense of nostalgia and remember how simple life was then).
I had an opportunity to take a role as a junior developer in the IT department working with the financial group, the group I worked with the first six years and excelled at because of the multitude of daily goals to achieve. I was a task master and couldn't stop myself.
Someone told me I couldn't do it, that I didn't have a degree in computer science so how could I think I could write applications. Now I think they were absolutely correct, and I would never hire anyone without specific experience. But back then I knew I could do anything I set my mind to. I was outraged they didn't feel the same. They hired someone else, who quit after three weeks, and suddenly thought I would do just fine. I was humiliated, angry, irritated, but took the job just to show them.
Slowly, slowly over time, I learned. My database skills were just fine. I could create tables to store data, normalize it to perfection, and even became an expert at multidimensional data cubes (where you store aggregated data at each combination of points where you could drill down into the data ). The bottom line is I was very good at creating data stores, again excuse the nerdisms here. The hard part was learning web development and creation of back end components (where the logic of the program is held). One step at a time, I learned it (one goal at a time) with no one telling me to do it.
Quickly I became very good at listening to a business problem, asking some questions, and immediately drawing the person a picture, literally a picture on a piece of paper, of how I envisioned an application would look like, what the pieces would be, and how it would interrelate to the other applications they already had. This is the part of my job I enjoyed. I often juggled eight applications at once, with thirty on the waiting list.
I resigned from this position for personal reasons over three years ago and have spent a lot of the time missing it, loving my freedom and time with my family, but feeling lost, feeling a need to be successful as a task master again, feeling a part of myself unfulfilled. I determinedly worked on computer certifications and developed web sites on my own, never feeling the same sense of purpose or happiness from this work.
Recently I stopped programming and started writing (the purpose for getting an English Literature degree 20+ years ago), realizing all of the time I spent on updating my computer skills after resigning could have been used to write a book, several books, or a hundred poems.
I recently had a realization that the time I spent doing software development has made me a better writer. Ideas have bubbled up in my mind from letting my mind rest a little without so much stress in my life. I have recently begun to apply the same approach to my writing as I did to application development, which is really working for me. The step-by-step process of application development fits into the process of writing and makes it seem like more of a job, a task that can be completed, something I can be successful at.
Even if you don't know much about computers, I think you can apply these steps to your writing if your goal is completion of a project:
- Requirement gathering
- This is the point in software development where you write down the general needs and begin to envision the finished product without all of the details.
- In writing, this is jotting down the idea for the story, the poem, the novel, whatever without trying to write the finished product.
- Mock up
- In software development, it's good to create a mockup of the user interface (UI), the part of the application that the users will put their fingers on, the part they can connect to. The UI is intended to not be perfect and is just a communication mechanism to make sure it kind of looks right with no real functionality.
- In writing, this is where I write a first draft, a free-write on the subject without any self-judgement while I'm writing. It's just to get out what I have so far and give myself an opportunity later to decide if I like that form (short-story, poem), if I'm missing anything. I have the opportunity to decide if I like it, if I want to pursue it, or if it needs to be tabled and put on the waiting list.
- In application development, the design starts with the database and the separation of work (application logic) into discreet components that can be re-used when possible. For example, a name would be entered in only one table and then connected to other tables for efficiency. A piece of application logic that fetches the name from the database would only need to be written once and referenced in the application whenever needed.
- The same is true in writing if you think of it this way. There is an underlying logic and efficiency needed. In my short stories, I reuse characters, I reference the same theme within multiple chapters of the same story sort of like a fetch to the database, careful to do this in a layered fashion, not repetitively.
- In application development the deliverable for this stage would be an entity diagram and a database diagram with the relationships between the pieces drawn together with lines. I do the same thing in my mind with a story or a poem. I think to type it up would ruin the creativity of it.
- In software development, this is done iteratively. You write one piece (or multiple pieces, one for each member of the development team) at a time and then test it. You test it by making sure it works, putting your hands on it, and asking others to check it for you. If multiple pieces are completed, you test them together to make sure they integrate seamlessly. You take the feedback and rework each piece until they are flawless together, or at least as flawless as you need them to be (especially if you have 30 other apps on the waiting list).
- I take the same approach in writing. This is where my writing class has been wonderful. I take a completed poem, group of poems, or chapter of a story to class after the writing is completed and it's as good as I can get it. Then I ask my immediate family to read it and give me feedback. Next I apply that feedback and print it out again. I read it out loud to make sure it flows. I edit and edit. And then I type out four copies and read it again in class and take the feedback of the women there (who are doing the same).
- The final step is project close-out and delivery.
- In software development, you go live with it, which is an involved process, much more than anyone would believe. It involves moving databases, applications, and backend components to production, being sure to purge any test data, and once again testing it to make sure all of the pieces are there. You apply all the permissions and test over and over again, you have all of the documentation in place and train the end users and support staff. When the application goes live, you hold your breath and wait and check the error logs to see if you missed anything while sitting by the phone waiting for questions or problems.
- In writing, I recently got to my first close-out. I submitted three poems to a local poetry contest. I am sitting and waiting. This was an easy close out. I am not confident what to do for my next few projects, where the attempt to get published will be more complex than following the rules for submission for three pages of poems.