The Developer’s Block
Just like writers, us developers can sometimes fall victim to a “writer’s block” or as I like to call it “developer’s block”. Sometimes we know what we want to create, but the blank file and blinking cursor is daunting to get past. Happens to me more often than I care to admit.
So what to do when this occurs? Well, usually I would try to just browse around for “inspiration”, find others solving the similar problem, or find something else kinda related. But in reality all I was doing was waiting for the block to pass. Very frustrating.
So a few months ago I set out to fix this for myself. Didn’t know where to start looking – talk about a block to solve a block (recursion eh?). During this time I was also interested in learning more about writing and how can I become decent at writing articles, emails etc.
During my research I found an awesome way:
Make a mess quickly. Too many times we worry about doing things the right way the first time. Writing the best algorithm. Creating an ideal data model. Organizing the code properly. You know, the tasks that look like productivity.
When in reality, I have found the the best way, at least for me, is to simply start solving the problem. It will be messy, ugly and most probably a sloppy solution. But all I want at this stage is to get to a working stage.
This does two things for me:
- It allows me to move forward. Without worrying about writing world-class code.
- It gives me a sense of achievement. It’s is very satisfying.
At this stage, I try to put some constraints on myself so that I can gain focus. The aim here is to create an environment that will force me to output something. Here are some of my rules:
- I allow myself to make mistakes
- I set myself a small goal
- I set a timer. Ideally 5 mins, but this would be different for all of us.
Now that I have something down in the editor, I do another short session (dare I call it a small “Sprint”?) to build upon this. I avoid cleaning up the code as much as possible. It’s okay to be messy. Focus on the task at hand. Once I have spent enough time building a rough first draft, it is now time to go back and clean up some parts of it. I start by just focusing on the glaring errors. Edit each function down to its essence. Can I cut the implementation in half?
This is a rinse and repeat process that allows me to move forward in small increments. Within few hours, I tend to have a base that I can build upon. There is always room for improvement. And as any writer would do, I re-read my code with a critical eye and this is when I start questioning my algorithms, data structure decisions etc.
What I found valuable, at least for me, was to use my “slow time periods” as clean-up sprints. This is when I know that I am approaching the end of the day or I am just exhausted or I am expecting to be interrupted by a meeting, call or someone. I would use this time for some low-energy tasks such as code readability, running linters etc.
This is very much an ongoing experiment. I have a lot of rough edges to iron out, lots of new problems to run into but I think it will always be an “on-going experiment”.
What do you do when you run into “developer’s block”?
