After reviewing some books I considered classics¹, I wondered what tomes were popular nowadays. I was disappointed to learn the #1 best seller on Amazon, in the category of data structure and algorithms, was Cracking the Coding Interview.
Was this a direct result of raising students on "teaching to the test?" Were companies so confused about hiring, they needed to administer a programming puzzle to find a suitable candidate?
The reviews ranked Cracking the Coding Interview highly, and the contents were substantive, not fluff. Yet, glancing over to my bookshelf, I would want candidates to be acquainted with titles like these: More Programming Pearls by Jon Bentley, The Cathedral & The Bazaar by Eric S. Raymond, Algorithms in C by Robert Sedgewick, and a classic-to-be, Joel On Software by Joel Spolsky.
When software development was novel (circa 1980), a popular notion was that the skills required for programming were similar to the skills needed in music and chess. Fi…
There was a time when I put a corporate seal on my favorite books. Dr. Stroustrup noticed the embossed seal, ran his fingers over it, and remarked "nice" as he signed my copy.
The book was published circa 1994, and Stroustrup was on hand to give a talk to an eager C++ user group.
While the book describes the early evolution of C++ -- the proposals, the decisions, the trade-offs, and the mistakes -- it is in the early sections where we learn most about the author. Stroustrup writes:
"It is often claimed that the structure of a system reflects the structure of the organization that created it. Within reason, I subscribe to that idea."
In my years of programming and working with management, I have found this to be very true. This was Stroustrup's way of saying the C++ language is largely shaped by who he is. While it's no surprise he has advanced degrees in mathematics and computer science, we learn that his hobbies include history and philosophy. Descr…
My first job had me programming in Microsoft BASIC for the IBM PC (DOS). BASIC worked well enough, but its limitations were clear. The language was interpreted and therefore slow. More importantly, it wasn't a modern structured language, and instead, relied on line numbers and the GOTO statement. Anyone who has read Dijkstra knew GOTO was a bad thing.
Having learned a structured language in college (PL/I), using BASIC felt unnatural. When a C compiler became available for the PC, I saw a chance to improve and modernize our software. The problem was selling the idea -- a problem made harder because I wasn't fluent in C.
"It would be a staffing problem. Not many people know C, but we can find a lot of programmers who know BASIC," noted one manager.
The argument was strong as my knowledge of C was weak. But I knew that C, by design, was a small language and thus easy to learn. "It has about 30 keywords," I proffered to another manager.