From all of my past experience in writing code and managing a project, I’ve noticed that more often than not. I find myself caught up in a web of limitations that I’ve designed myself.
The thing is that I usually have to weigh my options when I start coding between careful planning and “quickly getting it to work”. Either way, I tend to put aside this decision until it might be too late.
For some reason, pseudo-code didn’t appeal to me at first. Mostly because it’s based on your assumption of your code working, rather than actual solid proof that it will. What if you make an assumption that is flat out wrong, and what if the core of your program is focussed on that core assumption being correct.
Dense as I am, I always thought of “assumption” as a bad habit, or a bad point on pseudo-coding. But after giving it a whirl, I quickly noticed that NO. It’s a GOOD thing that you can assume everything.
You can freely dump your brain on 90% of your code that will do generic things. And you can get an early overview of how your code will work. It’s a huge relief, and it generates a good oversight.
Secondly, when it comes to reviewing that pseudo-code, you can spend some extra time investigating which components in your assumptions are critical, and evaluate if the logic used is true.