Starting to write something new like a new application, class, feature or any written work like an essay or blog post even can be very daunting. Defiling the blank screen or sheet of paper with your first scribblings can be very intimidating as you know you probably will not get it right the first time. This can lead to avoiding starting a task: especially one you are unsure of where to begin, even when you have the required technical ability to complete the task.
I experience this myself from time to time: I know what I need to do but I am unsure of where to begin and I will find myself actively stalling starting the task and do anything else instead. Later I will do the task and wonder why I put it off for so long: completing the task is easy but starting is somehow hard. The best way I’ve found of combating this sort of block is something a friend introduced me to and they called it dirty writing: it has nothing to do with erotica (sorry!).
The core of this method is that when you go to start a task you start writing immediately: it does not matter if what you are writing is any good or even compiles. It just matters that you are putting something down that you can then re-factor into something worthwhile. Otherwise it is very easy to sit at the ‘not sure where to begin’ stage for a long long time, which is highly inefficient.
For example if I am writing a new feature in a C++ application I will generally get started by:
- Creating the new source files for the new classes and associated unit tests.
- Adding the new source files to source control.
- Inserting the skeleton infrastructure into the files e.g. include guards and empty class definitions into the header (.h) files and #including the headers from their implementation (.cpp) source files.
- Define the test classes and their test methods for the methods of the new classes.
- Start adding methods and member variables to the classes in the header files and add empty implementations in their source files.
I find the above works quite well as defining the unit tests before I start to define the feature classes helps focus my mind on the interfaces of the new classes and what it is exactly that I require to implement the new feature and no more. I find if I start by writing the new feature first and then the tests that my implementation tends to end up more bloated with unneeded methods and code. You will notice that steps one to three are pretty basic, no advanced design or thinking is required, they just serve the purpose of gaining momentum in the task until I reach the stage I can start in on the meat of the task at hand.
How do you get past the mental block that a blank screen or piece of paper or empty source file can cause?
3 Comments
I sometimes get this with more complex features. What I sometimes do in such cases is fire up Visio, or take a piece of paper and put down some ideas. This usually helps to give a better picture of the task, especially if the architechture is large
Very good point Jani, I forgot to mention sketching! I guess that will be something for another post, sketching is usually my first line of attack on big systems too.
White boards! Before I had an office, I would take a conference room (in the off-hours) and work through my thoughts on a large white board. Lots of space, multi-coloured markers, easy to erase and to literally step back and look at the big picture, a white board is an essential tool in my problem solving process, both by myself and in collaboration with others. Concept sketches, process flowcharts, lists… with a digital camera or an iPhone it’s easy to capture the results. The point is, it doesn’t matter how or where, but the premise of dirty writing remains: get something down.
Post a Comment