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.
In my own career I believe I have done this to my own detriment. When I started programming professionally, the first language I really got into was PHP. It was much easier to learn and got the job done. At the time, Perl was the general alternative to PHP for web programming, but I couldn't get the syntax down fast enough; PHP, with it's explicit function names, had much higher "Google-ability" than all the @ and $_ of Perl, so in the short term, PHP made me feel more productive. In the long term though, it was counter-productive, as the programming habits I picked up didn't translate to other programming domains. As time progressed, the need to be able to program in other languages only continued to grow and I believe those early days hacking PHP have made that harder for me; currently I've been hacking Node.js related things and even though javascript isn't a complex language, I still feel a gap between Node projects and the PHP things I work on.
These days I worry about programmers starting their careers working with NoSQL systems, eschewing learning "hard" things like relational design, SQL, ACID, and CAP in favor of simpler systems that get you up and running quickly, but leave you with much larger problems down the line. I think the Javascript community realized this problem with the rising popularity of tools like JQuery; people started thinking of themselves as Javascript developers, but as soon as they bumped into the limitations of JQuery, they were lost trying to make Javascript do what they needed.
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.
