It happens to the best of us. You have a task to complete, you have a deadline, maybe something important like a deal with a big customer depends on you completing it on time and your boss is at your neck. You look at your code, it seems all dark and complex and tangled, little bugs that lurk at the corners of your IDE threaten to jump out from the screen and byte you
you get scared.
What do you do then? How does it affect your work? Should it affect your work?
When I was little, my mom used to tell me that I should always strive to make my important decisions in life based on choice, and not on limitations. When I grew up and studied art, my teacher told me that in order to build my own style I need to master my technical skills so that my style will be an artistic choice, rather than the sum of my inadequacies. The same principal applies here: you can’t program based on fear.
If your design and implementation decisions are guided by questions such as “Do I know the technology well enough to program this?”, “Do I know our product well enough to find the source of this bug?”, “Will I be able to design a plausible solution for this demand?” instead of “Is this the right technology/solution for my problem?”, “Is this course of action worth my time and effort?”, “Which strategy is most suitable for our needs?”, then you are not guided by what is best for your project, you are guided by what you can’t do.
Now, don’t get me wrong. The first set of questions are valid and very important questions, and we must ask ourselves these questions all the time, but they need to guide our self improvements attempts, not affect the way we code daily.
For instance, lets say I need to fix a bug in our product. I may decide it is best to dig for the root cause of the bug and fix it, even if it means refactoring some parts of the system (if it’s the beginning of the development cycle and I can take risks). Alternatively, I may decide the best approach would be putting a band-aid on the symptom and leaving the investigations for later (If this deal really depends on me releasing the darn patch already). It doesn’t matter what I decide – the most important thing is that I have a choice.
But if from some reason I am afraid to take one of these courses of action, then my hands are tied and I no longer make my choices based on what I think is best. For instance, if solving a bug requires me to refactor the system and I’m afraid to do that due to any number of reasons – either because I don’t know it well enough, because we don’t use source control in the company or because we have no automated testing and it is impossible to know whether I broke something in the process, then I have no choice but to use band-aids. If I do this for enough time, the software will reach such level of entropy, that even in my best intentions I will not be able to approach it without fear because every little change I make will have a rippling, uncontrollable effect.
This is why you must always strive to reduce your fear and increase your choices; because you can’t tame lions if you are afraid of cats, you can’t be a pilot if you are afraid to fly and you can’t be a programmer if you are afraid to code.
 Not funny, I know.