I wish I was done with the series of blog posts that helped me get over this! :)
I struggled with this for years and years. This is not one problem , but three: it is a problem with wisdom, speed, and discipline.
Luckily, we can learn tricks to improve each one.
If we want to attack this from the wisdom perspective, it is this: You are afraid of making the wrong decision because you are afraid to refactor. You are afraid to refactor because you don't have sufficient test coverage.
The good news is, for developers like us, test driven development is very helpful as a technique for getting us over these problems. If our team is not test-friendly, however, it will be difficult for us to make the jump because their code will not be written in ways to make it easy to test.
There are a few books I can suggest to help us jump the chasm:
1. Clean Code by Bob Martin. This book helped me think in more testable code, and also helped me understand how to make better decisions the first time around. It helped me by seeing patterns I didn't know first.
2. Refactoring by Martin Fowler. This one is old, but knowing the patterns of changing code gives us more confidence in knowing what is right, rather than hemming and hawing over what is readable and maintainable.
3. Refactoring From Legacy Code by Michael Feathers can help get from here to there. All of these help from three aspects: They help us develop a set of tests so we are less afraid of breaking existing things, they give us the freedom to experiment, and they help us break things down into smaller, more manageable problems by letting us think about "what is the next thing I can test?"
If we have the tests, we can be more aggressive in reducing complexity.
___
If we want to attack this from a Speed issue, then look for these things.
1. Look for patterns you use repeatedly, and try to settle down into a process. The fewer choices we make, the faster we can go.
2. Look to learn more about your chosen stack and language. It is possible that we are rewriting the wheel over and over. The more you understand the zen of your stack, the faster you can go and the more time you can devote to writing the same thing twice (without them knowing.)
3. Instead of hemming and hawing about the right solution, write all three. It is often faster to write all three and choose one than to get stuck in analysis paralysis. (That isn't to say you shouldn't think before you write code!)
___
Finally, you can attack this from a discipline angle.
1. Learn to meditate. By doing so, you can become more self-aware of analysis paralysis, calm your mind quickly, and mindfully choose a path.
2. Exercise. In the same way as meditation, exercise helps us learn to clear our mind and focus on command, and it helps sharpen our discipline chops.
With these, we can develop an awareness of how our body feels. Then we can develop an awareness of how analysis paralysis feels. If we can catch ourselves in the act, we can then institute something from our analytical skills: When caught in the trap, set 30 minutes on your timer, and bring out a pad of paper. If you feel you have the freedom, turn off the monitor.
Take deep breaths, and sketch out the solutions in the first ten minutes on the first page. Use UML or your own system.
In the next ten minutes, write a pro/con analysis on each path.
In the final ten minutes, make the decision. After this, your analysis time is up and you must code.
I suggest a combination of the above.
Good luck! It was one of the hardest things for me to defeat.
I struggled with this for years and years. This is not one problem , but three: it is a problem with wisdom, speed, and discipline.
Luckily, we can learn tricks to improve each one.
If we want to attack this from the wisdom perspective, it is this: You are afraid of making the wrong decision because you are afraid to refactor. You are afraid to refactor because you don't have sufficient test coverage.
The good news is, for developers like us, test driven development is very helpful as a technique for getting us over these problems. If our team is not test-friendly, however, it will be difficult for us to make the jump because their code will not be written in ways to make it easy to test.
There are a few books I can suggest to help us jump the chasm:
1. Clean Code by Bob Martin. This book helped me think in more testable code, and also helped me understand how to make better decisions the first time around. It helped me by seeing patterns I didn't know first.
2. Refactoring by Martin Fowler. This one is old, but knowing the patterns of changing code gives us more confidence in knowing what is right, rather than hemming and hawing over what is readable and maintainable.
3. Refactoring From Legacy Code by Michael Feathers can help get from here to there. All of these help from three aspects: They help us develop a set of tests so we are less afraid of breaking existing things, they give us the freedom to experiment, and they help us break things down into smaller, more manageable problems by letting us think about "what is the next thing I can test?"
If we have the tests, we can be more aggressive in reducing complexity.
___
If we want to attack this from a Speed issue, then look for these things.
1. Look for patterns you use repeatedly, and try to settle down into a process. The fewer choices we make, the faster we can go.
2. Look to learn more about your chosen stack and language. It is possible that we are rewriting the wheel over and over. The more you understand the zen of your stack, the faster you can go and the more time you can devote to writing the same thing twice (without them knowing.)
3. Instead of hemming and hawing about the right solution, write all three. It is often faster to write all three and choose one than to get stuck in analysis paralysis. (That isn't to say you shouldn't think before you write code!)
___
Finally, you can attack this from a discipline angle.
1. Learn to meditate. By doing so, you can become more self-aware of analysis paralysis, calm your mind quickly, and mindfully choose a path.
2. Exercise. In the same way as meditation, exercise helps us learn to clear our mind and focus on command, and it helps sharpen our discipline chops.
With these, we can develop an awareness of how our body feels. Then we can develop an awareness of how analysis paralysis feels. If we can catch ourselves in the act, we can then institute something from our analytical skills: When caught in the trap, set 30 minutes on your timer, and bring out a pad of paper. If you feel you have the freedom, turn off the monitor.
Take deep breaths, and sketch out the solutions in the first ten minutes on the first page. Use UML or your own system.
In the next ten minutes, write a pro/con analysis on each path.
In the final ten minutes, make the decision. After this, your analysis time is up and you must code.
I suggest a combination of the above.
Good luck! It was one of the hardest things for me to defeat.