Great Programming Books

I don’t write much about programming itself because….well….programming is as interesting as watching paint dry on the 4th of July. I have read one outstanding book on programming called Code Complete: A Practical Handbook of Software Construction by Steve McConnell. This book is better than all of the books that I bought for my computer college classes. (I majored in Information Science and minored in Computer Science, yeah go me!!)

Code Complete is very interesting even though it talks about computer programming. Specifically the book is aimed at “software construction” but a major part of software construction is computer programming. I re-read this book every year and it is just phenomenal. Amazon.com gives this book a 4.5 star rating with 149 customer reviews, which is a pretty strong recommendation. Feel free to buy the cheaper 1st edition since it has 99% the same stuff as the second edition. (I should know because I’ve practically memorized the 1st edition.)

It is really hard to describe “Joel on Software” written by Joel Spolsky. The book is just really, really good. The book is based on the author’s personal blog, http://www.joelonsoftware.com, but I find the book to be 100% more interesting and insightful than the blog. The book is hard to describe but it covers such computer science topics as “Why Anti-aliased text looks better”, “Network IO doesn’t work like local IO” and “Why there ain’t no such thing as plain text”. Overall the book isn’t technical but the author doesn’t mind diving in sometimes. The book is very humorous and I’ve found myself laughing out loud at it. (Warning your non-technical friends will not understand why the book is so funny.)

One really great essay from “Joel on Software” is the five worlds of computer programming. I’ll briefly go over the article but you can also read it here on his blog. The five worlds are shrinkwrap, internal, embedded, games and throwaway. Often an article or methodology will be talking about one world while the reader deals with a different world and then flame wars erupt. If a book is talking about shrinkwrap and you deal with open source, the book won’t make any sense to you. Each world is separate and doesn’t overlap.

Shrinkwrap – is used by zillions of customers, who often have alternatives. So the user interface needs to be easier than average to be successful. They spend half their time trying to make things even easier for Uncle Leo in Duluth.

Open Source – is often developed without anyone getting paid to develop it, so things that aren’t considered “fun” often don’t get done. (My comment – the user interface is often considered “not fun” and therefore never gets done. Most open source projects have horrible user interfaces that actually inflict pain on the user. And don’t get me started on command line interfaces that are as bad as the Sarlacc pit in Star Wars, i.e. very bad.)

Internal – only has to work in one situation on one company’s computers which makes it a lot easier to develop. You can make lots of assumptions about the environment under which it will run. You can require a particular version of Internet Explorer or Microsoft Office. Sadly lots of internal software sucks pretty badly even while accomplishing what it needs to accomplish. This can be depressing for young enthusiastic developers who need to be persuaded to stop when the software is “good enough.”

Embedded – is unique because it goes into a piece of hardware and in almost every case can never be updated. Even if it can technically be updated, it won’t be. Trust me, nobody downloads EPROM flash upgrades for their microwave ovens. This is a whole different world. The quality requirements are very high because there are no second chances. You may be dealing with a CPU that runs dramatically more slowly than the typical desktop processor, so developers may have to spend a lot of time optimizing and hand-tuning. Fast code is more important than elegant code. The input and output devices available to you will probably be limited.

Games – are unique. The economics of game development are hit-oriented. Some games are hits, many more games are failures, and if you want to make money on game software, you recognize this and make sure that you have a portfolio of games so that the blockbuster hit makes up for the losses on the failures. This is more like movies than software.

Throwaway – This category is included for completeness. This is code that you create temporarily solely for the purpose of obtaining something else, and you never need to use the code gain once you obtain that thing. For example, you might write a little shell script that massages an input file that you got into the format you need it for some other purpose, and this is a onetime operation. (My comment – throwaway code should always be saved for the future because you never know when you need to do “such and such” again. Usually if you need to do something once, you probably need to do it twice but you don’t realize it yet.)

Well after plagiarizing about 500 words you can tell that I really like the book. It is a very good non-technical book (only a few lines of code) that talks about technical subjects. Joel Spolsky wrote two very good books “Joel on Software” and “More Joel on Software”. He also edited the much worse “Best Software Writing I” which I mistakenly bought and it was a very BIG mistake. That book is horrible.

So in conclusion try to find “Code Complete” by Steve McConnell and if you want a good laugh or two read “Joel on Software” or “More Joel on Software” by Joel Spolsky.