Attitude in programming

From when I first learned to program on my family's C64, up through high school, college, and my first job, my only criteria of software quality was "Does it work?"  I prided myself on holding whole programs in my head, and making them do whatever I wanted, no matter how much time it took to get it working or debugged.

This attitude, it turns out, is hard to kill.  I see it in others, and I see it in myself, although I should know better by now.  

Some of my habits help fight this.  I generally write small functions.  My code is functional whenever possible.  Scope of variables is small. Globals are rarely used.  These habits help, but they still don't cover everything.

The main question is... "Is the code understandable?  To someone who hasn't been hacking at it for a week?"

Maybe like editing a paper, these questions need to be asked after a day or so or writing the code, so that the eyes are semi-fresh when looking at it.  Certainly a different set of eyes looking at it would be even better.

Most of the good practices (I mean the really good ones,  not just the popular ones) work towards making the code more understandable.    Even some of the other good goals, like managing complexity, seem secondary to understandability.  Managing complexity is necessary, but not sufficient to the goal of clear code.

When coding, it is very easy to just be done with something, without even a cursory check of how good it is.  So, how do I establish that habit?  I probably write more code at home, for fun, than I do at work.  That is probably where I need to build the habit, but it hurts a little to think of doing that extra effort for code that no one else will ever see, and that I might not ever look at again.

The habit may be worth it though.  Clearer code is more likely to be right, or at least easier to get right, instead of wading through the muck of something less clear.  Like clear writing, clear code should also encourage clear thinking.

That is a new goal of mine.  Let's see if it sticks.

Apologies

My apologies to the reader who was hoping for frequent updates.  Life got a little busy in February... I was contacted by a recruiter from a nice tech company, and then spent a month preparing to interview, and another month deliberating the choice, and finally another month recovering.

In the meantime, I have been working through The Essentials of Programming Languages.  The first edition sat in my night stand for about eight years.   Steve Yegge's post led me to this article (pdf), and inspired me to give it a serious try.

The book uses Scheme, so I started off in Common Lisp (since I want to learn it better).  I got the basic interpreters working, then tried porting it to Javascript.  After several days of slow going, I gave up, and went to Ocaml.   The pattern matching in the ML languages makes this kind of stuff much easier.  The EOPL book itself uses several macros to emulate the same behavior, but probably without the compile time checking.

None of this is new or exciting in general, but it is new and exciting for me.  I got a copy of the third addition of the book, and see that they build up to an interpreter with type inference.  That will be pretty cool to try, so I hope to stick it out.