Fears while writing code for the first time

Fear is an unpleasant feeling, a paralyzer. It doesn’t allow us to move forward. That's why we as humans need to identify when we are in fear and find ways to manage it in the best way. Believe it or not, writing code requires a lot of courage.

Blank-Page Syndrome

Many times when a writer starts writing a book or a blog post, as I’m doing now, they stare at a white page and wonder: Now what? What can I say that someone else hasn't already said? But more importantly, how do I get started?

Writers call this blockage the blank page syndrome. This obstacle is related to the feeling or sensation of not knowing how to start and the avoidance of starting a new project. It can also be associated with the fear of the unknown and judgement. Everybody can experience blank page syndrome which can hinder us from producing our best work and can hit at any point during any creative process. For example, in this state a writer might type the same sentence over and over again, isolating themselves from the world.

As code-writers, we deal with the same issue when tackling a problem for the first time. Problem solving requires a lot of creativity and can be daunting. Sometimes we also do things such as rewriting over and over the first line of code, not communicating with others and dreadfully staring at the computer wondering why you picked programming in the first place.

Analysis Paralysis

Besides, programmers have to deal with an additional state that leads to overanalysis of situations called analysis paralysis.

Analysis paralysis occurs when we try to assess too many options at once and we get overwhelmed by the amount of possibilities. We get stuck and come to no real conclusion about any of the options we’ve been presented. This results in many missed opportunities.

Analysis paralysis is strongly related to the fear of failure. Gathering information while dealing with a problem is useful. However, information in large quantities and performing an excessive analysis can increase the fear of making the wrong decision when faced with a new problem. Thus, we delay making this decision and don’t move forward with the solution of the problem that’s ahead of us.

Analysis paralysis and Blank Page syndrome share similar features, like re-writing, a sense of panic and not communicating with others. Others are more specific to the software development world, such as trying to model everything (classes, methods, etc.) in a piece of paper, creating complex structures in your head while doing it and crossing or wiping everything out and caring way too much about the details instead of focusing on the core functionality.

So what can we do?

There are many good solutions for both of these syndromes, like consulting with others, changing your workspace or even taking a break, but I will focus more on the Developer side of things. What can we methodologically-speaking do to prevent this from happening?

Well, one of the solutions could be to use Test-Driven Development.  As Kent Beck says in “Test-Driven Development by Example”, “Test-Driven Development is a way of managing fear during programming.”

Test-Driven Development (TDD) is a software development practice which includes writing your tests first, writing the essential code to make those tests pass and then refactoring. The basics of TDD are fairly easy to understand:  

First, add the simplest test you can think of. Then, run it and make sure the test fails.

After that, write the essential code to satisfy the test conditions; in other words make the red test become a green one with the first lines that pop in your head. Run all tests. If the code breaks any other test, rewrite the code until all of them pass. Repeat the previous steps until you spot repeated logic in your code. The last step is to refactor the code. This step is key to improve readability and maintainability to the code. Start the cycle all over!

What does this have to do with everything we talked about? With Test-Driven Development you know what your first step is: do a test! This helps us with the blank page syndrome, as it makes it easier to move forward and can partially dissipate the fear of the unknown. It also helps with analysis paralysis, as it narrows down your options and makes you focus on a feasible task.

Instead of trying to approach a problem in its entirety from the beginning, Test-Driven Development allows programmers to only concentrate on the next test. The TDD process as a whole segments our options and lets us establish goals to take on-the-fly decisions in an easier way. As a result, it allows us to focus on the core functionality of the code instead of the details, limiting the scope of the problem ahead.

This is good because it avoids creating a complex structure if you aren’t going to need it, also known as YAGNI for short.

Another advantage of this practice is the immediate feedback; if we are making a mistake, it can be fixed as soon as possible. In addition, error correction requires less effort and is easier to find what causes these mistakes. Errors are detected in early stages of development and are therefore less difficult to correct.

In short, mistakes have less negative impact on the person who made them and this can reduce the fear of failure.

It's not all a bed of roses

Working with TDD can be challenging, especially in the beginning. For example, when I had my technical interview with 10Pines I tried to use TDD and ran into several problems.

The first huge wall I hit was writing the first test. The most important thing when writing the first test is to make it as simple as possible. Paradoxically, this turned out to be more complicated than it seemed. I struggled to find a way to ensure that the test was indeed the simplest one as this can be subjective and different people understand different things by what simple is. If you want to learn more about how to deal with first test in TDD, you should read this article.

Another problem I encountered was that I had little experience with automated testing. In my college experience, testing was always put on the back burner, so I had to learn and brush up on several concepts in order to be able to deliver functional tests.

These problems eventually led to blank page syndrome as I didn't know how to start!

Somewhat frustrated, I started drafting a model on a piece of paper, crossing everything out and creating complex structures. Sounds familiar? Yep, I was suffering from analysis paralysis.

At this point, I decided to give up on the idea of doing TDD as it wasn't helping me. What I learned was that I lacked the practice to be able to use TDD; like everything, practicing is key to get the most out of TDD. As a personal experience, what helped me to understand TDD better was to solve a small problem with a known solution. For example, in the apprenticeship period in 10Pines I did an exercise(or as we call them ‘Katas’ ) where the objective was to translate from Arabic to Roman numerals. That could be a good starting point if you want to use it too!

In Conclusion

Dealing with fear is not easy, especially when we find ourselves trapped by the Blank Page Syndrome or Analysis Paralysis. Test Driven Development is a good method to prevent fear while programming, but not the only one and can be hard at the beginning. Even if you haven’t personally suffered any of these issues, I’d still recommend giving TDD a try.