I still believe in learning.
The computer trade is constantly changing. The knowledge base acquired for today's job will be almost useless for tomorrow. The knowledge base for tomorrow could be different because of technology change or more simply be a completely different part of the operating environment. Reading and learning are a constant requirement.
This section is where I make notes about books I have read. Some books are really good and I recommend that you add them to your reading list. There are a couple of books where I wish I could get reimbursement from the authors for wasting my time. One book was so bad that it caused me to doubt and ignore stl for two years longer than I should have. Books are a powerful influence. Here is where I tell how some have influenced me.
(I highly recommend this book.)
Source code is for humans to read and understand. Machine code is for computer processors to read and execute. A compiler or assembler will do the conversion from source to machine code. So a programmer should be most concerned with how humans will read his/her code, instead of machines. Steve McConnell's Code Complete focuses on how to write better code for humans.
I reread this book before writing the few paragraphs here. My first reading was eight or so years ago. I had forgotten that this book was the source of several code techniques that I have continued to use through the years. This time through the book, I picked up additional techniques for further improving how I write code.
A programmer should first read this book after a couple of years professional experience. Then come back and read it again five or so years later. There is only so much that can be absorbed in the first reading (ok, the truth is I only made it half way through the book the first time ... my original book mark was still there). It takes more experience with reading and editing other programmers' code to appreciate some of the topics. That is why the second reading needs to wait. Also the book would be a great source of discussion for a monthly team development meeting.
Code Complete is a book that is not based solely upon Steve's opinions. He regularly quotes research studies and other well known books. I noticed that the two chapters I liked most also happen to be the two chapters with the most industry data (called "Hard Data" in the book). My father is an anthropologist. He once told me that the first thing he does with his books is look at the bibliography. A good bibliography is the first sign of a great book he said. If dad liked writing code, he would categorize this as a great book.
McConnell, Steve Code Complete. Redmond: Microsoft Press, 1993.
The C++ Standard Library: A Tutorial and Reference
(I highly recommend this book as an stl primer and reference.)
Josuttis gives great insight into the history and use of the C++ Standard Library. The history of the library is important. It helps the reader understand the design decisions present in the current library. His presentation of the library's use is extremely clear. He covers the benefits of the standard usage model. Just as important, he covers the common pitfalls of incorrect use of the library. I wish this had been the first book I read on stl instead of the third.
I had tinkered with stl prior to reading this book. When I concentrated I could get through the various templates and odd functor constructs. I cannot say that I really had a true grasp of stl. That changed once I had read through chapter 5 of this book. Yes, the light went on. For the first time I could appreciate truly what stl was designed to do for me.
First I read the book. Now I use it as an everyday reference. Each stl component (containers, algorithms, adapters, etc.) has an informative presentation. The presentation is followed by a summary table of its operations and/or a comparison table with its peer components. This is a better stl reference than any other book or online reference I have.
Josuttis, Nicolai M. The C++ Standard Library: A Tutorial and Reference. Boston: Addison-Wesley, 1999.
(The best second book to read on stl.)
[Subtitle: 50 Specific Ways to Improve Your Use of the Standard Template Library.]
This is an extremely valuable book. Scott Meyers assumes you have learned the basics of stl somewhere else and played with it at least some. His goal is to discuss fifty usage topics in detail. Some of the topics discuss the entire stl. Others discuss only one or two containers. There is even a topic on how to understand the extremely long compiler error diagnostics (a welcome topic let me assure you). This is the book that takes you from just using stl to using stl well.
The bells and whistles of "Great Book" went off for me in the second topic. Meyers shoots down the myth that stl containers are interchangeable. He suggests that yes it can be done if you completely ignore how to use each container effectively. Then you can freely interchange ineffective containers ... but why. Based upon my personal experiences, I knew that Meyer had a picture of stl that I could understand.
I was not using stl heavily at the time I read the book. I will probably read it again in a few months now that I am becoming an active stl user. It is really best to have stl experience to get the full benefit of the book. Luckily, the book is short (approx 240 pages) and easy to read.
Meyers, Scott Effective STL: 50 specific ways to improve your use of the Standard Template Library. Boston: Addison-Wesley, 2001.
STL Tutorial and Reference
(Burn this book. Ask the authors to compensate you for time wasted reading it.)
I joined a company where the three existing programmers loved stl. Two of them had PhDs in compiler design from MIT. The third was working on his PhD. They gave me the big story about stl's component interchangeability and its performance guarantees. I once suggested they use a list object instead of a vector. One guy made a simple change to a header file, and nothing compiled anymore: so much for interchangeability. The performance of their stl code was horrible. Once I was so ticked off at the code that I rewrote it without stl. The performance changed by an order of magnitude (yes, it ran in one tenth of the previous time). stl may have performance guarantees, but those guarantees are only valid if you think about what you are doing.
This was the stl book they previously suggested I read.
I ended up not using stl much after this book and that employment. There was something in how this book presented the library and how I had seen it used that told me something was really wrong.
A couple of years later I would read Scott Meyers' book Effective STL. Suddenly stl made sense. Scott Meyers suggested Micolai Josuttis' book as a good primer. Another good suggestion. My suggestion is to shred this book and read the Josuttis and Meyers books instead.
Musser, David R. and Atul Saini STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library. Boston: Addison-Wesley, 1996.
Extreme Programming Explained: Embrace Change
(I highly recommend reading this book.)
Extreme Programming is a marketing name for this specific presentation on software development management. This presentation by Kent Beck is designed for the lowest level software manager and for the members of the software team. It is not an enterprise software development framework such CMM. The methodologies Beck presents do help a team achieve their part of an enterprise's CMM plan.
I have heard industry professionals speak of Extreme Programming, better know as XP, as a watered down attempt at CMM. Therefore these professionals dismiss XP in favor of the full fledged CMM and such. Wrong. This book has fabulous techniques that I had personally experienced years prior to XP's publication. XP mentions many of the development techniques I learned at Intuit. Today, Intuit has over one billion dollars in annual sales. It is also one of the few companies to regular fend off attacks by Microsoft. XP has a valuable place.
This book discusses the following essential development team topics:
Any small programming team could take this book as their day-to-day manual. Notice I said team. Beck's comments can and should be read by everyone, not just the team lead/manager.
Even better, the writing is very concise. The real content covers only 170 pages. A development team could easily spend 30 minutes a week discussing a few chapters. The team would discuss how to gradually incorporating (or not incorporate) these latest chapters into their workflow. The book becomes the team's first guide for development and productivity improvement. Wow, you would have to pay a CMM consultant big bucks to get this level of training and implementation. Beck makes it self help.
I have seen the value of working in pairs for design discussions and tough coding areas. Beck emphasizes doing this all the time. Not sure that I can agree on that point ... but I have never tried it either. His pair programming suggestion leads to a physical workspace arrangement that also seems foreign to me. Again, maybe you have to try it to appreciate it. Without trying it, the constant pair programming and workspace layout sections of his book are my only reservations.
Beck, Kent Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley, 2000.
Planning Extreme Programming
(I moderately recommend for team leads)
This book focuses on the project planning portion of Extreme Programming (XP). The topic is not covered in much depth in the first book of the series, Extreme Programming: Explained. I find this book to be written for the novice project lead. Much of the content is justification as to why project planning is good and necessary. The actual XP'ish planning techniques represent less than a quarter of the content.
The book is not what I had hoped. I once took a time management class where they give you time management day planners AND teach you how to use them. Beck and Fowler go so far as to say that paper systems are best for XP planning. But they never give more than two, maybe three, actual samples from their proposed paper system. I and every other reader are left with figuring that out ourselves. An example paper system that I can tailor would be far more useful than a paper system I have to create from scratch.
The book is written for novices and it leaves implementation details to the reader. Well a novice is not likely to have enough experience to create a paper system. An experienced lead or manager just might not read enough into this book to want to create a paper system. It seems Beck and Fowler miss both of these readers.
Beck, Kent and Martin Fowler Planning Extreme Programming. Boston: Addison-Wesley, 2001.
(Recommend only to those extremely motivated in unit test implementation / presentation.)
This book is tedious reading. You need to go into it with a strong desire to learn about unit tests and/or test automation. In my case, I was ready to revamp my unit test model and was looking for some outside influences. It really helped that this was the only book I took on a Southwest Airlines flight from Boston to Houston. Otherwise I might never have finished it, or would have finished it over such a long period of time that the continuity was lost. I guess at the genesis of the book based upon some comments made in chapter 17. It appears that Beck took a training presentation on unit testing and converted it to book form. I bet the live presentation is much more captivating.
Kent Beck is again writing a full book on one XP area that is covered lightly in Extreme Programming Explained: unit testing. The book's first section builds awareness in two items: Test-Driven Development, TDD, through one on-going example and the requirements a test automation harness will have. This is the really tedious section. The second section implements a basic test automation harness the reader can use while simultaneously providing another TDD session example. This is again somewhat tedious reading due to the example. The final section becomes the reader's reference for personal Test-Driven Development sessions. Yes, this really looks like a reasonable adaptation of a successful live training presentation.
The content is primarily for the individual programmer (or programmer pair in true XP). It is not a QA manager's guide to measuring unit tests. There is one chapter that quickly mentions various coding metrics. The metrics are mostly mentioned to emphasize the efficiency of the TDD methodology. The discussion does not suggest why or how metrics like code coverage should be used within a group. That is a managerial level issue. Again, this content is for the direct code contributor.
This book is a great guide for the individual that is going to introduce and/or establish unit testing personally or within a group. Its strength is in showing how to present the concepts. The book's weakness is that it is too tedious to expect every programmer to finish it individually.
Beck, Kent Test-Driven Development: By Example. Boston: Addison-Wesley, 2003.
An Introduction to Programming in Emacs Lisp
(A quick start into Lisp and Emacs coding.)
This is the book format of an on-line tutorial into Emacs Lisp programming. It is well written and loses no impact by being printed. Robert Chassell does a good job of getting the reader proficient with both Lisp syntax and the Emacs' Lisp conventions. I chose the read the book instead of the on-line version so that I could spend the time reading somewhere away from my computer screen, i.e. around my family.
Through the years I have used so many editors that I have lost track: ed (CP/M), WordMaster, med, Brief, CodeWright, Visual Studio, etc. For a few years now I have been popping back and forth between Windows and Linux. It final became easier to standardize on Emacs for both environments. My fingers are good at learning one set of editting control keys, but not two. Emacs was a reasonable choice for both environments ... and it is free.
Now the time is overdue for me to learn how to adjust Emacs to some of the editing shortcuts I loved in other tools like CodeWright. This book gave a good introduction to the nature of the Emacs code that I will be reading and potentially modifying (or maybe just reading and finding the right parameters to customize). You should read this book only if Emacs is your designated editor.
Chassel, Robert J. An Introduction to Programming in Emacs Lisp, 2d ed. Boston: Free Software Foundation, Inc., 2001.