Right Tools For The Job
After reading some of the many posts by my AltDevBlogADay colleagues this “meta” post started to formulate in my mind, here are examples of what triggered the train of thought that led to this one:
- Object Oriented Programming. However, this covers the whole range from the large concepts like OOP to smaller tips and tricks for being more efficient, concise or correct.
- Yourself – You’re the person making however much of the application/game/service, so this makes you and your well-being just as important as any other element.
For many people these things will be obvious and they are, everything should always be considered for a piece of work however and often aren’t. Especially in the slightly less soft elements like languages and libraries all of them need to be viewed and assessed in context and in relation to each other. You may well be the most amazing Haskell guru the world has ever seen, but choosing Haskell for writing a tool for managing a list of assets in Windows is likely not the best idea for the project or the other 20 developers working with you.
Take this as an empowering way of viewing the projects you do, everyone before you may have done something a particular way (see “nobody ever got fired for buying IBM”) but for you and your project it just may not be the right thing to do. Make the choice of how something is done based on the project and who’s working on it, using the right library may be the right choice or write your own if you really think it’s the right thing to do.
Become a polyglot, it will pay off and you’ll feel better for it. As has been said before, aside from time, experimenting with software tends to have zero costs so playing around and seeing what can be done is worth it. I will end this with one personal piece of advice however, Perl is never the right tool for the job!