Mark Needham

Thoughts on Software Development

Best tool for the job/Learning new ways to do things

with one comment

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 me Apprenticeship 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?

Written by Mark Needham

March 24th, 2013 at 10:01 pm

Posted in Learning

Tagged with

  • http://twitter.com/DataMiller Matthew Mark Miller

    There are an awful lot of tools out there, all doing the same or similar things in slightly different ways to meet somebody’s specific needs. To try to learn all of them is folly; learning more than one or two tools exercising the same technique is surely filling a skill gap, but the gap isn’t likely very wide.

    Learning is not a zero sum game. The cost is opportunity: two hours spent learning a new JS framework is two hours spent not getting betting better, or solving problems with, your current framework. Across a busy team, maybe it’s 10 hours, or 40. Or, alternately, investigating something brand new. IMO the value to learning Clojure, if you don’t know any functional languages, is that it’s an example of a brand new paradigm. Hey maybe you’ll get into it, fall into R development, and cure cancer.

    Being able to evaluate tools for their aptness to a task isn’t without value, but it is often less valuable than being able to make do with tools you know really well (and can hire cheap people to maintain). If any solution that meets the requirements is correct, time spent in evaluation beyond that is often pursuing marginal value. So it’s pretty unfair to expect developers with problems to be concerned with picking the exact right one. I’ve seen decent systems written on what would seem like ungodly hacks, and also seen the correct technology perverted by inexperience.