Coding and writing: two sides of a creative coin

I have another article up at Forensic Focus. This time it’s a Top 10 list (I know, as if there aren’t enough of those on the interwebs) covering the best the digital forensics community has to offer.

As I researched this list, I noticed that most had a few things in common:

  • Many of the posts riffed off one another, with posts either continuing research or running with tangential ideas someone else had started.
  • The bloggers post regularly because they want to solve problems that they and other people experience.
  • The bloggers are, for the most part, also coders who write their own forensic tools for the benefit of the rest of the community.

This got me thinking about the similarities between blogging and coding:

  • People think both processes are complex, and therefore, it takes some special skill or talent to do “right.”
  • People tend to think that they lack this skill or talent, that they cannot “be good at” writing or coding.
  • People further tend to think they have nothing to say that hasn’t already been said.

It starts with solving a problem

Writers write to express, inform, explain, question, suggest, hypothesize — often for the same reasons that coders program scripts and plugins. Those reasons: to solve problems or add to a larger discussion about a problem or opportunity.

Most forensicators must have had the experience of learning that their go-to forensic tool doesn’t do what they need it to. There’s that extra level of functionality needed to complete a particular investigation, or a piece of evidence needed in a more convenient format.

Often, it takes a unique blend of experience and knowledge to recognize these problems or opportunities for what they are, and to start to tease out a way to articulate them. Without that articulation, both writers and coders know, there is no resolution.

It takes time and effort…

Neither of which you have in any great supply, right? Yet a final script or plugin, like a final manuscript, doesn’t happen overnight. You start small, outlining the problem you want to solve or the theme you want to write about. Then you start filling in the blanks.

In my (admittedly limited) experience with coding, the problem often starts with some new functionality I want to add to my website. At this stage of my business, still bootstrapping, I don’t want to pay a developer; WordPress makes things fairly simple. What the core product doesn’t cover, the plugins do — there’s even a Simple Custom CSS Editor.

I’ve never enjoyed coding, never thought of myself as good at it, but knowing there had to be a simple solution, I used a trial-and-error process of Google searches related to my WordPress theme — and was able to work out how to make hyperlinks in my blog underlined when hovered over.

This doesn’t make me able to add “WordPress development” to my list of services, obviously, and it was the sort of fix that didn’t take a lot of extra time out of my workday. But that one small stretch out of my comfort zone will help me better communicate with my partner web developers, and if I wanted it to, grow to a hobby or further… kind of like writing once did.

… but it doesn’t need to be perfect

There’s some irony in my dispensing this advice; I’m known to keep at an article until it flows properly. The Forensic Focus article was, in fact, one of those; as I worked on it, I kept finding new candidates that met the criteria I’d laid out for myself — to use a loose analogy, new variables that challenged my hypothesis.

However, running up against the deadline I’d agreed on and needing to get to client projects, I adjusted my coverage to accommodate some of the newer voices in the community. I then decided the piece was “good enough” and, with a final quick edit, filed it.

When and how do you decide something is good enough? This is a tough one. For me it’s intuitive, something I just feel, but I think that has a lot to do with process. Mine goes something like this:

  1. I brainstorm an idea. It’s usually something I’m really excited about, so I capture my stream of consciousness on paper. Then I lay it aside.
  2. Several days or even weeks later, I come back to it. I flesh it out, explore my rough arguments, add to them with references from other works if I can, expand them. Then I lay it aside again.
  3. Another few days or weeks later (depending on whether I have a deadline, and if I don’t, my motivation level) I again return to the piece. This time I’m looking for the gaps, loose ends, and other flaws. I can then decide whether to follow through with them, abandon them, or save them for future projects.
  4. I wrap it up, polish it, give it one last quick read-through, then post.

I imagine this process might look similar for a coding project. The key is to find the process that works for you. That can, in itself, take time through trial and error — a tough prospect when you have a job and a family and pets and a life. You might even decide that you’re overextended as it is, and you can’t motivate yourself to move forward.

But I’ve also found that the things that stick with me over time are the things most worth making time for. Devote even fifteen minutes a day to a project or post (or the post that describes the project), and you may be surprised at the way something comes together.

Of course, it helps to have feedback on something that’s new to you. If you think you need help working out a blog strategy for your coding, business, or other DF/IR projects, send me a message, and we’ll talk!

One thought on “Coding and writing: two sides of a creative coin

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.