Yesterday I was sharing my screen in a Skype call when we were debugging a broken Jenkins build. During the call my colleague noticed that I was opening the console output of a running build by clicking on the build number in the Build Executor Status sidebar, waiting for the page to load and then clicking on the Console Output. He told me that by clicking the circle next to the build number would take me straight to the last position of the Console Output screen.
In the past 5 years I have used Jenkins almost every day of my professional life and I thought I knew it well. I was the go-to Jenkins guy in some of the companies I worked for and here I was learning a trivial new thing that effectively halves the time it takes for me to perform a common task. A task that I have done thousands of times before.
I realised that in the case of Jenkins I have violated my own rule about software:
my rule of thumb: If you use a (software) tool more than 1 hour a day: read at least one book on it.
I strongly believe that if you learn a new tool only by using it, you will eventually start using it in wrong or sub-optimal ways. As demonstrated by my Jenkins anecdote above. Because the way I was performing one task worked, I did not stop to think if there was a better, more efficient way to do it.
Simply reading a book or manual on the topic will expose you to more features and alternative ways for doing things. I noticed 3 main benefits from reading more about software:
In early 2015 after months of pain in my wrist and fingers I started the transition from emacs to Vim as my main editor. For months I was googling for answers every time I wanted to perform an action I had not done before. After 10 months of googling and improving my Vim chops I thought I was doing well… and then I picked up a copy of Learning the vi and Vim editors by O’reilly and was proven wrong.
In 5 hours I learned about the origin of the editor, its roots in the ex editor, ex commands, the use of regular expressions in almost every command.
Those 5 hours I spent reading the book have already saved me countless hours of tedious text editing work. Because the book has a few in depth topics about regular expression syntax, not only my Vim skills but also my command line skills improved.
A few years ago when I was learning Emacs I read an old emacs manual from 1997 written by RMS himself. Aside from countless keyboard shortcuts and features that improved my editing efficiency it also thought me the core philosophy of Emacs: a text buffer as the universal interface.
After reading this book it became clear to me that Emacs is not just a text editor but a tool for interacting with software through a text interface. After that I started using emacs for taking notes, IRC chat, email and as an HTTP client.
When I was learning Git 6 years ago I read Scott Chacon’s book Pro Git. I finished it in a couple of hours, spread out over two evenings and – as with the Vim book – the result was amazing.
After reading this book I had a thorough understanding of how Git worked, why it worked like that and I was able to apply this knowledge to any Git problem I have encountered since then. Almost overnight I went from the guy asking basic git questions to the guy everyone turns to for git questions.
I want you to take a look at your own programming habits and identify a tool you use at least one hour each day and you don’t know that much about. This could be your text editor, version control software, build tool, CI server, programming language or something else. Then go out and find a learning resource that will teach you everything there is to know about it. This can be a book, a manual, the documentation or even the source code.
I guarantee that the time you invest in reading will pay of huge.