When programming, I have observed that the time I spend on figuring out the skeleton and the structure of a program is much longer than the time I need to write the program. Some people argue that this is a good thing, that people should think about what they do, before they actually do it. But being a aspiring craftsman, code is what gives me the greatest pleasure. There are a lot of cases where I tried to think through before actually coding and failed miserably.
For one, I decide to write a twitter client using adobe air just for the fun of it. I spent so much time figuring out what the application should do, I created off a repository in github and eventually, did not manage to check in a single line of code.
There are certain myths about thinking through what you have to do, that need to be broken. For one, you can never think about or reason about something that you have no idea about. Of course, you would have some idea about programming, and I presume, that is the reason why you are reading this post. But back to the point, even though you have a sound understanding on programming, it is very difficult to come up with a structure for the program you have to write NOW. This is because each program is unique in itself, though there might exist some commonality.
To overcome traps such as these, I find it useful to create some concrete artifacts that give you an idea of how to proceed. The following are some artifacts that I find to be really useful. I call them feedback generators.
Code : Nothing provides so much clarity than the first line of code that you write.
Unit test : Feel like code is in the wrong place? write off a unit test. You need to set up a lot of variables before you can get to the assertion? you have written the code in the wrong class.
Comment: Though code is the most rigorous and most helpful artifact, I sometimes find that enumerating a set of tasks as comments is quite helpful.
Hypothesis: I have found it to be really useful in pin-pointing the source of a defect. If it is correct, gotcha!!!, incorrect? probably you would have a better understanding of the defect by the time you found hypothesis 1 to be wrong.
The Dumbest solution: I have in some cases found it useful, to think about something that is so obviously wrong, but it eventually leads to a better solution.
Similar solution: Solutions to similar problems are tremendously helpful resources.
Wish list: When writing a program, we create data structures. When writing algorithms around those data-structures, it is tremendously useful to create a wish list of information that you would have liked the data structure to have to make your life easier.
Some artifacts, that I have found to be tremendously wasteful.
Writing down and mind maps: These just reflect what you think, and never have helped me to figure out the solution to a problem or in writing a program.
The counter example: When I am writing a program or solving a problem, I try to find a failure case as soon as possible. The disadvantage of this is that, I don’t see the few things that I am doing correct, and end up back in square 1.
Meta physical questions: Like should the Person know about a test. Nothing is as wasteful as this. If you end up in this discussion, write off some tests that consume the information and see if it should or should not have a reference. Also I have found normalization to be a good technique to answer these kind of questions.
The important thing to remember when using feedback generators, is that, one should start reasoning based on them, once they are created. If one goes off into a tangential line of reason, the feedback generator will be ineffective, and would have eaten up precious time.
I am trying to apply these feedback generators in earnest whenever I write code. I will post back, with updates on how well I fare.
Quote for the Day,
“If you want to survive here, have an opinion” – House