Skip to content

Choosing the best tool for the job

I’m involved in a lot of communities and write a lot of different code — but I know my Python friends think of me that way, my JS friends, JS, and so on. When I was on the Shop Talk Show, I talked about being a programming polyglot and about choosing the best tool for the job. Lo and behold, I got a question sent to me by Kris:

On the show, you were talking about choosing the best language for the job. For example, sometimes you’ll choose Rails, sometimes Python, and sometimes Node. Can you give me some real-world examples of what you mean? I am familiar with PHP and Ruby on Rails and I know what Python and Node are. I just don’t understand when one server-side language/platform would be better than another.

First of all a very important aside — any of these tools only matter if you have a clue how to use them. For example, I don’t know Scala (yet!), so I’m not going to say it’s a viable option to build anything big on.

Anyway, here’re some examples of things I’ve done, to answer question: what are some practical examples of choosing a tool for the job?

Problem: I have a dataset that I need to massage or load into a database with some care and then do X with it.
Tool: Python and Django. Python because I can do data massage well with it, Django because if I’m going to put it on the web, it gives it a great structure really fast, and it’s very explicit about what’s happening (very Pythonic), something I care about a lot with data.

Problem: Build something to engage a community around a topic, expose a limited (smaller) amount of information to them.
Tool: Rails, because we can build it fast and get it out in the field, there’s probably gems/libraries for any community engagement stuff I want to build, and there’s also not too much ‘stuff’ in the background to worry about. For Rails, it is my humble opinion that the acrobatics that people have done for security/scaling don’t make it worth doing large projects (and I’ve worked with big Rails … it gets hairy).

Problem: Build a site that’s essentially static, maybe with some user interactive on the front end.
Tool: This is where I might use Node. The main programming I need is the interactive, so the other bit is how to serve it. Definitely not an impressive use of Node, but Node/Express can be even easier than Flask for some of these problems, if you like just shipping it all in JavaScript. For me, Node is also great for apps mainly interacting with JSON APIs (well, that’s most APIs, right?) without much backend, because you can make what-have-you on the UI layer and serve it in JS as well on the back-end.

More abstractly — if you’re a polyglot, or trying to be, be sure to know the strengths and weaknesses of your tools. I personally find Rails slow, which can annoy the heck out of me on a project; I find it very annoying to have to work to speed it up, rather than using say, Django, where I know if it’s slow, it’s my own damn fault, because my code explicitly includes everything when it includes it (namespaces, let’s do more of that). At the same time, Django doesn’t really have much on Rails in terms of going 0 to 60 when you use some scaffolding to cheat to win.

I’m not going to tell you what to use, but I will tell you to get better at the choosing process, which is another blog post.

I know a lot of developers who teach themselves more languages — but I think it’s only fun if you actually use them. I also think there are some developers who are too dogmatic about their own tool. If they never stick their head out of the sand, how will they drive their own community forward? And with that, I leave you with two silly tweets I wrote after being frustrated with some of these ostrich developers:

5 Replies to “Choosing the best tool for the job”

  1. Great post!  It definitely served as a good reminder to keep an open mind and learn as much as I can.

    Your first two examples made total sense.  However, I’m not sure I understand your third example about Node.  I’m sure it’s because I don’t know very much about Node.  When you say it’s essentially a static site with some user interactivity, why wouldn’t you just create a static site using HTML/CSS with some regular front-end JavaScript or jQuery for the interactivity?  Like I said, I’m sure it’s because I don’t understand Node or I didn’t understand what you meant by “static site”.

    1. I like to serve even mostly static sites with better backends so I can do things like use templating and such. It is definitely fair to say “just use some HTML files!” but then I’d have to do things like change the title and h1 on every page, where if I use some form of routing/templating combo, I can store the name of the page in a variable and pass it to the template. Hope that helps!

      1. Ah. Makes perfect sense! I’ve often wondered the same thing. I’ve thought about using PHP just so I could take advantage of the “includes”. I just thought it would be overkill. Nice to know it’s not.

        1. If you don’t need much more than “includes”, think about using Server Side Includes (SSI). It’s a very nice little scripting language built right into HTML, as long as your server supports it, for the times when PHP would be overkill.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.