[This post reflects my own views and in no way reflects the views of any past, present, or future employer of mine.]

Recently, I was reintroduced to an article written by Zed Shaw named Deconstructing K&RC where he criticizes Brian Kernighan and Dennis Ritchie’s book, The C Programming Language.

Like most of his articles, it’s very interesting, detailed, and fun to read. However, he touched on something in those introductory paragraphs that I would like to reflect on. Namely, the thought that “The C Programming Language” is somehow infallible and should be read without question should not be your mindset when picking up this book. Paraphrasing, Zed goes on to say that this

established piece of programmer lore … needs to be taken down from its pedestal and relegated to history rather than vaunted as state of the art.

Harsh words when applied to a specific text, but I encourage everyone to take this open mindset when consuming any kind of technical content. Consuming an “established piece of programmer lore” will be a good use of your time, as it will most likely contain a good amount of valuable information, but it should not be treated as gospel. Likewise, any one piece of content should not forcibly shape the direction of your career. Instead, have an open mind and a critical eye on everything you consume because anything powerful is influential.

As always, Zed wraps up the intro, so eloquently, by stating after being critical of the text,

You will … have an informed opinion of the book’s actual quality, and will be able to make your own decisions on how to use the knowledge it contains.

Being informed and making your own decisions given what you know while removing influence and bias is actually a core tenet in my career. This was solidified after a No Fluff Just Stuff conference where Neil Ford was showing the differences between design patterns implemented in dynamic languages vs static languages. Being fairly early in my career, this talk was the first to really show me the true power of dynamic languages, groovy in this case, and I was super impressed. This talk made me look at Java, which was used in the talk, like it was an abacus in comparison. I was influenced. Big Time.

Being a noob, I waited until after the Q&A to ask a question 1 on 1. I asked Neil about job prospects in Groovy and what references I can read to ramp up to be productive with Groovy in my career right away. He told me to slow down, research dynamic languages in general to see how they could fit into your developer toolset, and make your own decision about the direction of your career outside of this talk. I felt like I was just slapped out of a dynamic language stupor. This bit of advise from Neil has stuck with me since and I’m very much glad that he slapped some sense into me.

Getting back to the Zed article, I really feel this is the underlying message to the whole post and I hope it wasn’t immediately lost on those that have an irrational feeling for that book. Because that message has been extremely important in my career and one that I have considered to be very powerful. But, please, come to that conclusion on your own.