The first puzzler was a big success with 33 comments added as I write this today. I wanted to go over some highlights from the comments and code that people put out there for critique.

First off, I want to say that several people posted code that solved the problem. I do not want to get into the specifics of any person’s code, that was done in the comments section. I do want to use this as reason to lay out some coding philosophy.

• Many people did not fully test their solutions and often failed on edge cases.

It is difficult to test any algorithm completely, especially when the answer is not known, but how do you know if your answer is right if you do not know the answer at all? I tested all submitted code, and often just running a bunch of random test cases lead to “solutions” that did not make sense. In this puzzle, some solutions came back with answers like “Remove rows 3 5 5”. This is a mistake since you can not remove the same row twice. In other cases, the returned matrix had an all zero column, so the job was not yet finished.

Running a lot of test cases really helps

• The code was ‘too clever’

I know we have some very clever programmers here, and that part of the fun is to find a clever, terse way of solving code in the least number of lines. We have dedicated contests to just that challenge in the past.

When I am coding ‘for real’, I know that someone else is likely to need to read and understand the code. That someone else might be me in a few weeks once I have forgotten everything about the code! I like to have descriptive variable names, and easy to understand algorithms.

I would rather have ten lines of code that is easy to understand rather than five lines that will take me ten minutes to understand. The simpler and more intuitive the algorithm, the less likely that edge cases will fail.

Sometimes you want to have that ‘clever’ code for reasons of efficiency of memory or speed of execution. My thought is get the code working once, then profile it to see where the bottle necks are. Fix those slow areas, sacrificing readability for speed of execution only if needed. There is no need to make ‘speculative improvements’ to speed code up when it is not needed.

• Solve the problem by hand first

Some people misunderstood the problem. I very often will solve problems by hand on a white board so I am sure I understand the problem and the solution I intend to use. It is possible to work out this entire problem by hand.

Many problems that MATLAB users are working on can not be done by hand at all. However, engineering is the art of breaking complex problems down into pieces that are solvable. This problem originally came to me from a MATLAB user, and I highly suspect it is just one small part of a much larger problem he was solving. Once this is solved and tested, he can encapsulate this into a MATLAB function and not worry about it again!