If your current programming task is loose, without much specced details, you’re in trouble. You will be engaged in a constant ping pong and redoing/rethenking probably 80% of your work.
Worst than that, whenvever you have to make more than 3 decisions in a row, let’s take these 3 for example:
- Color of the title
- Text of the placeholder
- Refactoring legacy method, or leaving it be
The next decision you will make probably going to be shitty, unless you will empty your decision pool by doing the first thing that comes to your mind, just sticking something to it. That’s exactly what I’m doing now, a struggle between the flow of thought which feels natural, without much pondering, or the opposite, drilling down every specific detail. This two states of mind are opposites and we as professional programmers, and, well, people, should be aware of the implications of each state. There are times that we need the first and times when we need the second. You move from one state to another in cycles/iterations which reminds me of Agile or Scrum methodologies.
I prefer to call it cycles. First cycle is laying groundwork. You write down whatever you are going to construct, without getting into detail. It’s essential that you won’t be tight about it or it will shoot you in the leg and bark the whole night at you and you won’t get to sleep and you’ll be tired the whole next day, because you were perfecting one measurable piece of stupid napkin paper.
Okay, cycles, first cycle: write something down. It should be a general plan, the outline of the algorithm, with as many specific details as you fancy as long as it won’t take too long.
Second cycle: start implementing that pickle. Now, you need to follow through your plan. Whenever you are stuck, trying to decide something, if you don’t come up with an answer straight up you should write down the question and follow through. My advice is to use some note keeping software, this is the stuff of legends, Evernote specifically. Don’t have a note keeping software? Please do yourself a favor and download one. This is the most important thing, emptying your decision pool. This will later lead to better decisions because you won’t be not under stress to figure it out instantly in order to proceed implementing it. Sometimes stepping back gives you a better perspective later when you deal with the issue. Some examples:
- Not sure if singleton is the right way, ask Walt
- Duplicating that code because I want backward compatibily and afraid to screw up, ask Walt
- This graph looks shitty, ask Walt why are we plotting number of stars against day of the year
Third cycle: ASK THE QUESTIONS, WRITE DOWN THE ANSWERS
and we go back to cycle 1.
That’s it, pretty simple aye?
In my opinion, it’s the best analytical process for every task there is. It’s the key to your success, life fulfillment, and Arduino side projects. Don’t be torn by details you don’t know. You shouldn’t decide and implement at the same time, it’s counter productive. Lay some groundwork, do some lifting and iterate your whole life, separating decisions from the flow of your actual doingness ( . Read about decision fatigue: https://en.wikipedia.org/wiki/Decision_fatigue
From the wiki article: There is a paradox in that “people who lack choices seem to want them and often will fight for them,” yet at the same time, “people find that making many choices can be [psychologically] aversive.”
Aversive is bad if you are wondering about the alignment of that adjective.
P.S I live by this rule, and written this article in the following cycles:
- first cycle (groundwork): 5 minute (99% of the article)
- perfecting: 10 minutes afterwards (rephrased three sentences, added this paragraph and put some commas)
- perfecting: 15 minutes couple of hours later
Because the actual task is writing, cycle number 2 which is implementing is the same as cycle one.
It took me thirty minutes to write this post, instead of days of proofreading each word which otherwise would have been my destiny.
To sum it up, we have a limited pool of decisions. When developing software this can lead one to be stuck many too often and to lower the quality of the decisions she makes. Instead I suggest to use your notes as a bank and deposit every question there (with some constraints of course) and proceed in the meantime to follow the sketch you have done before, in so called “cycles” or “iterations”.
Agree ? Disagree ? You use some different technique ? Do tell.
SerjDroid 