Sunday Thought: Patient / Fast | Dru Sellers
Some times I am such a dolt.
I open a new OSS project and my first thoughts are usually “This library is ^&*$% it doesn’t do anything right.”
“RAGE! (╯°□°）╯︵ ┻━┻” don’t they know that, MY WAY is better!
Its sad, but that is exactly what I am thinking. I am on such an immediate gratification high, thanks to my 8 core, 8GB RAM, SSD, super high speed internet capable machine that I forget that not everything can be measured in sub-second latency. Things like instant on-demand movies, and Amazon 2 day shipping don’t help with my attitude either. When it comes to learning, this demand for instant gratification has, many times, gotten in the way of what it is I really want to accomplish.
So, I ran into this situation again this week, and after IM’ing the maintainer – complaining about how this and that worked (ok, lets be honest – I was whining like a 4 year old) – I kinda just snapped out of it. I recalled a quote from the book The Toyota Way, where they stated that the #1 problem with new engineers is that they can’t slow down. They just want to charge into things head first and solve all of the problems. Hmm, sounds a lot like me. Except that I have 10 years underneath my belt now. So, why am I still acting like a new developer? My biggest guess, is that I haven’t really honed my process. I need more people to catch me acting this way and to call me on it. But that can be hard to find in our community, because we all tend to act this way.
We, developers, are always on the look out for the next shiny library or framework that we can “learn” and by learn I mean implement. We like libraries so simple that a new programmer could understand them. We don’t want a learning curve at all. I think that this is one of the reasons things like express.js, flask, and sinatra play so well in our community. You can see, immediately, how it works. They have almost no abstraction over the underlying concepts. Let’s not forget, that its the abstractions that bring the real power, and that not every abstraction is a poor or leaky one.
Its Sunday, which is an introspective day for me, and I want to try and improve myself. I think that if I could work on this aspect of my skills and attitude, I would become a better developer. Being a better developer is something that I want to be. Ok, so how am I going to do this. After much thought, I was reminded of a similar experience that worked well for me outside of the software development world.
For that last three months I have been training in Olympic Lifting. Now for those of you that have never performed olympic lifts, you need to know that while strength is a big part of it, skill also plays a huge part. You can’t just hoist 150 pounds over your head with out a level of skill. The snatch is an explosive lift, that requires an insane amount of patience and balance. My coach and teammates have a phrase that I have come to love. “Patient / Fast”, which means to me that you have to move fast, but at the same time be patient in the pull. It took me a long time to really grok that concept. It feels like a damn Zen koan at times, but I keep repeating the phrase and each day it reveals itself to me a bit more.
So there I was, at the keyboard, about to burst a vein, when I woke myself up from my emotions, calmed down – and asked myself what would “Patient / Fast” look like here? I decided that I would patiently look through the code, asks questions to myself via comments and then go answer them, and start to understand what the code was doing, on the flip side I would be very fast to start writing, running, and debugging unit tests to get ahold of the code base. Sure enough, the code started to reveal itself to me, I could see the author’s intentions much better now. I started to build up a good amount of understanding, and was able to effectively solve my problem but was also even able to make a nice pull request back to the library that I think cleaned up a very small part of the code base.
In the end, I spent more time than the old me would have liked understanding the library. But the reality of it is, this small investment in understanding a key part of my infrastructure is going to pay dividends in the long run. And less than a day understanding how a critical part of my system works, is indeed a small investment. So, from here on out I am going to remember. Patient / Fast