Over a million developers have joined DZone.

The Best Tool for the Job

DZone's Guide to

The Best Tool for the Job

· DevOps Zone
Free Resource

The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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.

In this context he’s referring to javascript libraries but I think his thinking is generally applicable.

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.

If I want to quickly put together a simple web application I’d use Sinatra but would one of the Python equivalents be better if I was more familiar with Python or does it not matter?

I’m reminded of conversations that I used to have with Ade when we worked together and he was showing meApprenticeship Patterns and in particular the ‘Confront your ignorance‘ pattern.

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?

The DevOps Zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today


Published at DZone with permission of Mark Needham, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}