This function could well be submitted as a CSOTD to worsethanfailure.com:

//unique solution number

public static long solutionTime ()

{

long enterMilliSec = System.currentTimeMillis ();

long checkMilliSec = System.currentTimeMillis ();

checkMilliSec = System.currentTimeMillis ();

return checkMilliSec;

}

Not only is it not unique (Hello “race condition”) but checkMilliSec is assigned twice and enterMilleSec isn’t even used. It’s a good thing Java has garbage collection.

Several of the methods he HAS written could be replaced by a single line. Also, the convertToString() method should be called toString().

That said, I do occasionally find myself spending more time coding than thinking. Or, more accurately, more time debugging than thinking. The reason for this is mostly due to inexperience with the language in question. Being a Sysadmin now, rather than a dedicated coder, I tend to switch from Perl to PHP to bash to C to C to Java depending on what is needed. Frequently, the language that is most appropriate is one that I haven’t used before or haven’t used for a long time. Most of the programs I write these days are exceedingly simple and don’t require all that much thought anyway. I also tend to have to debug other people’s code when they put it on the live server and it breaks everything. I don’t get the luxury of “thinking time”… I have the CEO or my line manager on my back asking when things will be working again.

There’s a great book called “The Pragmatic Programmer” that discusses a lot of this stuff. They mention the “DRY” principle and go into detail about many other things that affect real-world coding. Definitely worth a read.

Developing software is a lot of mental labour, which is difficult for people outside the field to understand. After completing a task I’ve set out for myself, I like to go out for short walks — get some fresh air, relax my eyes, refresh the mind. 5 minutes out does absolute wonders. Actually if I’m stuck at a problem, same also helps to think from a new perspective.

Though back when I was working for a not-so-technical department at a University, they were pretty strict about such things. I was supposed to be on the clock and in the cubicle 9 to 5, actual results came second. Naturally I’ve made a decision to never come back to such kind of establishments, they are completely missing the point of what they are hiring developers for.

The director of operations, at a company where I once worked as an engineer, went to the VP, Engineering and said, “Every time I walk past David’s office, he has his feet on the desk and his hands laced behind his head.” The VP said, “Good, that’s when he’s doing his best work.”

While I think DRY is a Good Thing, I don’t think immediate refactoring is necessarily good. The danger is that the two things turn out to be not quite the same, and then you have to introduce some conditionals, and you end up spending more time making your abstraction work than making your program work. I think it’s better to copy the code and only refactor once you know it works. Premature refactoring can lead to wonky abstractions.

http://ponderousprog.blogspot.com/2007/11/taking-time-out-pause-innovates.html

In fact, I tend to write programs the way I write stories. First comes the rough draft, then comes the first re-write, THEN I design the structure and layout, then comes the second re-write.

Then I start thinking about trimming down my code.

It may not be efficient, but it’s fun!