Larry Marks wrote:
3) how they attack a problem, do they start with paper/pen ? Do they start with big items and work smaller or just start working it out on the keyboard?
Personally, I make sure I understand the problem as best as I can before trying to implement a solution. In this case, that may mean sitting down with
a pen and paper, writing a "random" sequence of 5 - 10 integers, and then stepping through the pseudo-code of the insertion sort algo. At each iteration
you'll mark exactly where the loop pointers are pointing, note when you've found the correct insert location for the integer (and how you knew that), then
manually shift however many integers are required to their new location, etc...
Then, I would implement the algorithm in the absolute simplest code possible (i.e. forget about generics, implementing Comparable, writing test code
before you even understand how the code is supposed to execute properly, dynamically resizing arrays, input validation, etc...). If the bare bones
implementation works as you expected it to (based on your whiteboard/notebook practice stepping through the algo), THEN comment it very well so
that Future Larry will still love you (Present Larry) when he has to read it again at some point.
Now, if you need to implement additional bells and whistles then introduce them one at a time, making sure you completely understand (and test) them
as you go along. That way if it doesn't work, you know exactly which changes are causing the issue. Trying to implement two (or more) features into your code
before you understand what you are doing is just asking for frustration. Tomorrow-morning-Larry (the one who got some sleep tonight because he sensibly implemented
one new feature at a time) will be very appreciative of you for sticking to this process.
And, now I've got about 15 minutes to get to class, so I'll sign off here.