Why does the dog wag its tail?
Because the dog is smarter than the tail.
If the tail were smarter, it would wag the dog.
The phrase wag the dog refers to times when something of a secondary importance improperly takes on the role of something of primary importance. As I watched the recording of Tim Ewald’s excellent talk Clojure : Programming with Hand Tools it is the phrase that popped into my mind when Tim concluded that
The tools that you use shape the way you view the world.
Tim’s talk is on the dangers of blindly automate with tools without fully understanding them, and one of the strong points he made is that instead of being the master of our tools we have so often allowed them to dictate us instead. If you consider the programming languages we use as part of the tools in our developer toolbox, they have a similar ‘wag the dog’ effect on us as they restrict the possibilities we see and the solutions we are able to create when faced with a problem.
If all you know is object-oriented and imperative programming, then how will you even know if a better, more elegant solution exists with functional, logic or other programming paradigms? Or that they don’t?
In his letter to the Budget Council of the University of Texas, the great Dijkstra wrote:
[…] functional programming immediately drives home the message that there is more to programming than they thought. […] It’s not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits. […]
The best way to overcome the limitations and “shape” that our tools have placed upon us is to actively seek a broader perspective, by exposing ourselves to different ways of thinking. What better way to do that than to try out different programming paradigms and languages. Luckily for us, we’re spoilt for choice at the moment – F#, Clojure, Scala, Haskell, Erlang, Go, Julia, Dart, Elixir, Rust, the list goes on, and each offers something unique and interesting.
In his inspirational talk The Future of Programming, Bret Victor offer a glimpse into a past that many of us was never fortunate enough to experience; a past that had so much more variety because there was no preconception about what the “right” way is, so all of a sudden everything is possible and everything is permissible!
It is a sentiment that is shared by none other than Alan Kay, who spoke of a wealth of history that are worth revisiting as you ponder about the future, in his 2011 talk Programming and Scaling.
To wrap up this short post, don’t let the languages/tools we use master us, broaden your horizons by learning and seeing the possibilities that your tools/languages might not want you to see, better yourself and become the master of your tools.
Be the dog that wags the tail.
I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.
Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.
- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong