The Best Tool for the Job
I recently came across an interesting post written by Randy Luecke titled ‘I’m done with the web‘ in which he expresses his surprise that people often aren’t willing to take the time out to learn something new.
Having worked for a few years now I’ve played around with a reasonable number of programming languages/text editors/databases/etc to the point that I have favourites when it comes to solving certain problems.
If I come across a new problem and I want to solve it quickly my first instinct is to use one of the things that I know and am comfortable with as this will allow me to solve the problem most quickly.
The problem with this way of thinking is that it’s restrictive – what if there’s some other way of solving the problem which is actually better than what I’m doing but would take some practice for me to recognise that?
For example at the moment if I wanted to hack together a script which used a Java API I’d probably just crack open IntelliJ and write the code in Java even if clojure might be a better choice if I knew it better.
You have identified gaps in your skillset, gaps that are relevant to your daily work.
In this case the gap I’m talking about is relevant in as far as you can arguably do a better job if you have more tools to choose from.
A common pattern that I’ve noticed myself/others doing is to stick with the toolset we’re comfortable with until it breaks down at which point we start looking around for something else.
While this approach does work it feels like we should be more proactive in learning new things so that we can question whether are current tools are actually the best ones for the job rather than just assuming they are.
I don’t really have a conclusion other than that Randy’s post struck a chord and I want to try and always challenge myself to keep learning things.
It’d be interesting to know if others have a similar experience or if I’m way off track?