My most important programming book

My first employer had a great library. Tons and tons of books, multiple copies of the most popular books, and you could keep a book until someone else needed it. They would display new books for people to look at, and then have a sign up sheet to borrow the book when it went into circulation. From that program, I first read The Pragmatic Programmer, by Andrew Hunt and Dave Thomas.

At the time, I was only a year or two out of college with a fresh math degree and a bunch of Computer Science coursework. I wasn't really a programmer. I was a math / computer science nerd who had a programming job. When I started the job, I was paired with a mentor who taught me better practices at programming than what I picked up at school. Sadly, I cannot recall exactly what she taught me, because it all became ingrained in the way I work. I feel that it was things that are obvious to software engineers, but maybe not to math majors (to be fair, I believe she was a math major too, but had been working for ten years as a developer).

Then one day, I found this book at the library. I read it all in about two days. The stuff I have really taken from it is not really about programming, but the craft of programming, and ways to get better at it. When I left the job, I had a list of books I needed to buy … this was near the top of the list.

Some of the things I got from this book were the importance of learning the tools that I use for programming. I learned the about knowing your editor very well, learning a text processing language, and how much time the command line can save you. This led to me learning Emacs, Python, and Bash (then Z-Shell) pretty well. I am not an expert in any of these. I cannot do real tricky stuff off of the top of my head, but I do know where to look to figure stuff out. These skills are now some of my greatest strengths, though they don't really translate to a resume point very well. Part of how I get things done fast is that I let my tools do a lot of my work, and I am willing to spend time writing code to do my work for me.

Learning Python also fell under their recommendation to learn a new language every year. That is a goal I haven't really met, either, but I have probably read tutorials and documentations on far more than the 11 languages I should have learned the last 11 years. I just don't have applications for many of them, so I don't really learn them.

Version control was another topic I learned about from this book. **Gasp**. I know. It was 1999… I was a math major. Ok, I should have known better. I first learned RCS. CVS was a huge step up. I got along with CVS pretty well until Subversion came out. Then I flirted with several distributed version control systems, and am now pretty happy with Mercurial, although it looks like I need to be conversant in Git to get along in the open source world today. I have used Darcs, Arch, and Bazaar enough to say that I walked through their tutorials, and I remember some of the quirks of their developers.

There are some basic software design ideas in this book, but I think I learned a lot more about actual software from the references in the appendices of the book. This alone would have been worth the cost of the book to me. Again, remember it was 1999 or 2000. The appendices had a list of internet resources for things like programming languages, shells, editors, mailing lists. I went through a lot of those links. All the Python, Emacs, and Bash skills I built started there. Now that I look at it, even Z shell was in there.

Even more important was their bibliography of books. So, I was able to find the books that interested me easily from the library at work. The Practice of Programming, Effective C++, Sedgewick's Algorithms. From this start I was led to Programming Pearls, Code Complete, Writing Solid Code. I was humbled by many, but none as much as The Art of Computer Programming. (I'm not pretending I have managed to read much of that, and I still haven't bought my own copy)

Much of their soft suggestions seem like they should have been obvious, but Hunt and Thomas's book set me on a path of growth as a programmer. As a computer scientist too, if I can call myself that. They helped push my interest in computer languages to where I can now understand, but maybe not write, code in Lisp, Haskell, and Ocaml. I have looked into many languages, and for the most part only read enough to understand why they are different (Forth and Lua, maybe).

This book taught me some important things, but mostly it taught me that I have a lot to learn. That is what makes it the most important programming book I have read. Other books may be better, but this is the one that opened my eyes.

Stackoverflow -- finally answered a question

Got my first selected answer on stackoverflow!  I waited several days to post the full solution, in case the competition in question was still running.  My hope was that people would down vote his question if that was the case.

My solution isn't elegant, but I thought it was a nice example of a recursive function that goes beyond the factorial function you normally see.  Ok, it isn't really a good example of recursion.   It is an example of using tail recursion to eliminate mutable variables that you would use in a while loop.  Oh well.

Othello in Javascript

A few times I have tried this strategy to learn something new. I try to convert some code from a book into a different language. Just copying and running examples out of a book isn't very exciting, and it doesn't force me to understand what is going on in the code.

But porting to another language forces me to understand (better) what the original code is doing, why it is nice in the language used, and how to do the same thing in a different language.

The last few days, I ported code from Peter Norvig's Lisp AI Book into javascript. Learning more about lisp has been a goal of mine for years. Learning javascript is a more recent goal. I have always been interested in AI programming.

Here is the work in progress. Here are some of the known deficiencies:

• very little testing or cleanup has been done
• the GUI is a hack
• there isn't a timer to let the computer know it took too long. On a fast computer, 6 ply look ahead may not be too bad
• yeah, my use of the google app engine is probably lame. But it serves my static file for me.

The javascript code has a variety of influences. Norvig's code, of course, provides an often literal example. Crockford's book and website were a big help, although I probably didn't succeed in getting the good parts right. My F# experience led to the m_array library object at the top of the javascript file, even though everything I do in that library is probably available in javascript somewhere else.

I probably won't try to add the more advanced AI code from the book, and instead move on to playing with it in lisp.

If you see any dangerous problems here, I would like to know about it.