Longer By Way Of Shortcuts
By: Robert Treat 29 Jan '14
The other day I was hacking on a project and I needed a quick dashboard showing the number of times a given process was running on my machine. A simple mix of ps, sort, and uniq, except that I only cared about a subset of processes, and I needed to make the display easy to read. OK, I thought, I'll just use cut for that. But it turns out using cut on ps is actually hard. Well, not hard; but certainly not straightforward due to the spacing issues between different output columns, and that I typically use cut is on fixed width/field outputs. Looking at the cut man pages, I thought to myself, the real solution to this is awk. In days gone by, awk (and it's counterpart sed) was considered the standard for manipulating text streams, but it suffered because most people felt it had too high a learning curve. Instead, tools like cut were created which focused on solving text manipulation problems 90% of the time with a much lower learning curve. While that seems like a huge win, it is, unfortunately, also a trap.
Since cut solves most of my problems, I've used it for cases where awk could have solved my problem, but it would have taken longer to figure out how. In the short term you would think that would be what you wanted, but the downside is that, at this moment, when I had a problem that is trivial to handle in awk, I couldn't remember the syntax because I don't work with awk regularly enough. Of course, we are just talking about two different shell commands; it only takes a few minutes with either tool to Google what you need to do. But I see this behavior repeated by software engineers where it does become non-trivial; reaching for the "easy" solution to solve the problem in front of us, but undercutting our ability to learn more difficult, but also more powerful, tools and techniques.
Now perhaps you are thinking if the time comes when your simple tool is inadequate, you'll spend the effort to learn the more complicated tool, but that's not the way that learning works. Most people need those simpler use cases to gain familiarity with the tool before taking on more difficult problems. "Teachable moments", where you have the time and lack of pressure to explore something and really understand how it works. When you see someone who looks like they have mastery over some "certain set of skills" that you wish you had, they didn't get that by waiting for a complicated problem to manifest and then start learning something new.
We choose to go to the moon in this decade and to do these other things not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win.
President John F. Kennedy, 1962
Maybe mastery of craft is not something for everyone, but I would encourage folks to try to explore tools, systems and experiences that they find challenging, or that might seem a bit more difficult that you'd expect. If you have ever found yourself looking at a problem that requires using a tool that you just don't know how to use and wish you did, I'd encourage you to take that tool and see if you can find simple use cases for working with it, even if you already know a better solution. This is the way you train yourself, and this is the way that you prepare for those times when the non-trivial comes knocking at your door. And it will come knocking.