Unless you have a super-awesome job (and lots of people do), programming in your own time may be the only way to discover and play with new things. If you work backend at a C# shop but would like to start writing Ruby, you're unlikely to get the opportunity to learn unless you do it in side projects.
Practically, you may be totally happy in your current niche, but you're at higher risk from technological obsolescence unless you diversify.
This is as much an argument for '20% time' as it is for programming at home.
You don't have to have a super awesome job, for example one company I worked for went through a phase where they didn't have enough coders to cover support and development for about 9 months.
We spent 95% of our time fielding calls from users (no first line, management's bright idea) and fixing bugs on old legacy code (vbscript when everyone else was on C#).
There were some developers who got a lot more support calls done than the others.
And then there were some developers who would refactor the code, write tools and other little programs and upgrade the in-house support system to make everyone's life easier and quicker to fix the bugs, learning while they did it.
It probably won't surprise many that those two sets comprised of exactly the same developers.
What about the auxiliary scripts that need to be written for some tasks to automate some task that is ancillary to your product? If you are writing a ruby script for those tasks that are useful but could be done by brute force methods I don't see a problem with that.
Automation of deployment or some menial task, sanitizing test data, gleaning statistics from a csv dump of the database, cron jobs, etc... I'm sure you could come up with more.
>What about the auxiliary scripts that need to be written for some tasks to automate some task that is ancillary to your product? If you are writing a ruby script for those tasks that are useful but could be done by brute force methods I don't see a problem with that.
Pfft.
Any semi conservative workplace, anywhere: "What? No, who the hell would maintain it? Stick to <tools of choice>."
Although I like to think I'm a bit cooler and down with the times and the hip words the kids use would probably say something like, "So help me god, if I have to learn Erlang at three in the morning to fix some bullshit you cobbled together I will fucking end you".
I didn't mean anything that other people use. Just scripts that help you out; those scripts are for you and you alone. They help you do you job more effectively but do not require you to install them on other machines. It depends on the size of the company for where the level of latitude stops though.
Actually this is where we let our developers experiment a bit. Obviously nothing too out there but just because you're a Java shop it doesn't mean that Java is the best tool for everything you might do so it can make sense on a few levels.
but you're at higher risk from technological obsolescence unless you diversify.
For the same reason that a developer can produce something using a new technology on spare time, the same developer can pick up a new technology, at work, in a brief period of time.
In other words, I think it's largely B.S. to talk about 'obsolete' developers. You could only be obsolete if you entirely forgot how to learn, which I think is impossible, barring something like singularly maintaining the same COBOL system since the 70's.
Practically, you may be totally happy in your current niche, but you're at higher risk from technological obsolescence unless you diversify.
This is as much an argument for '20% time' as it is for programming at home.