Picking exotic languages

Dear colleague, and you intend to develop in a language that has lukewarm company support: don’t do it.

It’s hard enough debugging someone else’s code, and it is even harder debugging unfamiliar code written in someone else’s language, with an unfamiliar tool (like emacs) that I haven’t even installed on my workstation, with unfamiliar semantics (e.g. is an empty list false ?)

When you go on your holidays or fall sick, some one has to support the code. Especially when a customer calls up with a show stopping bug. I’ve got family and kids, and would rather not stay at work late just because a colleague had taken a language to his fancy, and decided the next project was going to be done differently.

By all means, if it is the right tool, then persuade the company to support it overwhelmingly. That means every guy in the team will be sent to courses to learn it, there are licenses for every developer, that the toolset will be deployed into all developers standard development environments, and you will be doing additional code walkthroughs so that no guy is left behind.

Leave a Reply