Ridiculous Coding or The problem with writers block

A happy new year to you and thank you for reading this entry. Most bloggers immediately blame their schedules for their lack of presence on their blogs. I don’t want to blame my schedule, instead, I want to blame my lack of faithfulness to following through.

My big desire this year is to write a book (along with finding a way to create some passive income - more on that later). I’ve started writing and was off to what I feel like is a good start but not without a lot of trepidation and fear in getting that start. An author friend of mine, (Donnie Bryant)[http://donnie-bryant.com/], offered the advice that I should just aim for writing two pages per day even if they are bad quality, but just to write. Then he said, “just write, don’t edit.” As an engineer, this makes little sense to me. I think about efficiency and best practices whenever I go to write anything. I’m not well versed in the philosophy of writing but I think the gist is that if you keep writing you’ll grow in your skills and eventually produce high-quality content. If you write a short story every day for a year eventually you’ll write at least one great story, right?

I’ve been teaching a coding boot camp and one of the things I’ve been doing is spending time helping some of the struggling students by doing live coding sessions on off hours. In the latest session, I worked with a student who suffered from some serious bouts of analysis paralysis. She thought so much about what to write and whether or not it would be good that she actually wouldn’t write anything. She felt fear, confusion and even some obligation to not let me down in the process. As I began to coach her I uttered, “just write something. We’ll fix it if is broken later but for now, just write.” Then she began to write code. We worked through the broken parts, but she began to write! Every time I would sense her locking up, I reminded her to just write. This is where I had my major eureka moment! I was encouraging her to do the same thing that I had been encouraged to do. I almost wanted to tell her to follow a new pattern:

• Write a small snippet of code
• Ensure that it works by running it (note, just that it isn’t broken via syntax)
• Write some more

I encouraged her to not worry too much about the syntax and formatting as we could fix those things later. The biggest issue is that we didn’t have anything to fix so we had to get past the blank screen. I’m not sure how much this helped her versus the real impact it had on me. I tend to over analyze things when I’m thinking of a new project or a new piece of functionality. Sometimes I’ll spend too much time thinking about it and end up doing nothing (hello, analysis paralysis). I can hear the alarms sounding and the red flags going off. HOW CAN YOU WRITE CODE WITHOUT A PLAN FIRST?! I agree! We need a plan, but we also need to write something. My student hasn’t been introduced to the notion of test-driven development so the only real planning tool she has at her disposal is pseudo-coding. I always emphasize the importance of that. What I’m getting at here is that we once we’ve devised a plan, we should immediately start finding some ways to get past the blank screen. That could easily be starting with tests or it could be creating a file and throwing some comments in there to mark the places where the future functionality will be. The game-changing step here is the action.

Considering all of this - I’m going to try the “ridiculous” technique in both writing code and finishing my book. The only thing separating me from others is the ability to be faithful to the follow through. I want to be faithful, do you?

P.S., Thanks for the reminder, Pops.