On Psuedo-Coding

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.


About McBuff

Working as a Revit & Blender 3D "artist" in a retail world. I've graduated as a chemist, and have graduated as a "technical artist" in the world of "interactive 3D". I have that classic dream of one day working as a coder or designer in the sector. I think that the value of the product quality is more important than profit margins and release schedules. A view that sadly is in stark contrast to reality. Generally I am more interested in aspects of life, than aspects of industry. I'm opposed to taking things seriously, when they do not benefit mankind or me. ( But that's just an opinion ).

Leave a Reply

Your email address will not be published. Required fields are marked *