Out of the gate, into a wall
Almost immediately after committing to this project, I'm faced with a major hurdle to productivity - indecision.
Prior to starting work on a new project its important to at least have a rough idea of a feasible overall structure and design goals. For me, this is a challenge - particularly the "feasible" part. I'm prone to over-planning and perfectionism which makes the adopting the mindset of "this is good enough" quite difficult.
For the structure of Civis Ortus, I'm considering (among other things) the following issues:
For the structure of Civis Ortus, I'm considering (among other things) the following issues:
- The game should be easy to patch
- The game should be easy to mod
- The code-base should be highly modular
Of these, 2 considerations are "perfectionism" goals - easy to patch, easy to mod - and 1 is about professionalism and managing executive dysfunction.
I've got two competing decision making parts of my mind. There is the rational decision maker, and the monkey shaman. The monkey shaman differs from the instant gratification monkey in that its wearing a blindfold and earmuffs and sits in a smoke filled emotional control room beating drums. The monkey shaman sits at the controls of my emotions and loves to shout judgements and (doom & gloom) prophesies.
I've got two competing decision making parts of my mind. There is the rational decision maker, and the monkey shaman. The monkey shaman differs from the instant gratification monkey in that its wearing a blindfold and earmuffs and sits in a smoke filled emotional control room beating drums. The monkey shaman sits at the controls of my emotions and loves to shout judgements and (doom & gloom) prophesies.
Whilst the rational decision maker is trying to consider things such as "Its important to make the game easy to mod because it is a sandbox game - and people like to mod sandbox games", the monkey shaman is screaming "Get it perfect, or no-one will ever play it", "It won't matter, you're an impostor who can't code anyway", and "What if you find a better way later?" whilst blindly smashing the buttons (not levers, its all or nothing with my dysfunctional emotions) to release stress hormones and adrenaline into my system.
With every klaxon blaring, the rational decision maker must blindly wade through the smoke-filled control room to reset all the switches - but its a near impossible task to get them all, and the effects still linger. With executive dysfunction, I get similar physiological responses to perceived events as I would to actual events. When the monkey shaman screams "You're gonna do it wrong and break the game!" I feel the same emotional reaction as I would if I had actually made a mistake that broke the game for everyone - even before I've started working on it!
All this means that when I am rationally considering a course of action - such as a basic structure for the project - I'm already knocking into the effects of executive dysfunction. Prior to being able to recognise what is going on, I would find myself locked in indecision. If encountered too many times, I would develop an aversion to the task/project because of the stress involved with even approaching it. This in turn leads to procrastination and avoidance. Now that I'm more aware of what is going on, the rational decision maker part of me can understand that these feelings are transitory - I've just got to ride this wave until I can find a way to break off and get back on task.
One of the best phrases I've found that encapsulates the shift in mindset that I have needed to make is "Anything worth doing is worth doing poorly". Its a philosophy that clashes hard with my perfectionist streak. At a superficial level, it seems to be saying "half-ass anything important", but that is so far removed from what it actually means.
Anything worth doing is worth doing poorly - its OK not to do it perfectly. If its worth doing, any progress is better than no progress. Do the bare minimum that you are able in order to progress, then, if you are able, refine it.
Anything worth doing is worth doing poorly.
With this in mind, I am choosing to "do it poorly". The basic structure I choose may not be perfect, and may make things harder later on, but its progress. Any progress is better than no progress.
With regards to the third consideration I had listed above - the code-base should be highly modular - this is necessary in order to reduce the friction required for me to start on a task. The less I need to pre-load into my head prior to beginning work the easier it will be to begin work. This also has the upside of (hopefully) creating less spaghetti code.
With every klaxon blaring, the rational decision maker must blindly wade through the smoke-filled control room to reset all the switches - but its a near impossible task to get them all, and the effects still linger. With executive dysfunction, I get similar physiological responses to perceived events as I would to actual events. When the monkey shaman screams "You're gonna do it wrong and break the game!" I feel the same emotional reaction as I would if I had actually made a mistake that broke the game for everyone - even before I've started working on it!
All this means that when I am rationally considering a course of action - such as a basic structure for the project - I'm already knocking into the effects of executive dysfunction. Prior to being able to recognise what is going on, I would find myself locked in indecision. If encountered too many times, I would develop an aversion to the task/project because of the stress involved with even approaching it. This in turn leads to procrastination and avoidance. Now that I'm more aware of what is going on, the rational decision maker part of me can understand that these feelings are transitory - I've just got to ride this wave until I can find a way to break off and get back on task.
One of the best phrases I've found that encapsulates the shift in mindset that I have needed to make is "Anything worth doing is worth doing poorly". Its a philosophy that clashes hard with my perfectionist streak. At a superficial level, it seems to be saying "half-ass anything important", but that is so far removed from what it actually means.
Anything worth doing is worth doing poorly - its OK not to do it perfectly. If its worth doing, any progress is better than no progress. Do the bare minimum that you are able in order to progress, then, if you are able, refine it.
Anything worth doing is worth doing poorly.
With this in mind, I am choosing to "do it poorly". The basic structure I choose may not be perfect, and may make things harder later on, but its progress. Any progress is better than no progress.
With regards to the third consideration I had listed above - the code-base should be highly modular - this is necessary in order to reduce the friction required for me to start on a task. The less I need to pre-load into my head prior to beginning work the easier it will be to begin work. This also has the upside of (hopefully) creating less spaghetti code.
Comments
Post a Comment