Usefulness to yourself is sometimes the only thing that matters. I'm not trying to be snarky here: your own self-development is not anyone's interest, except yours.
If you're a PHP developer wanting to start some Python, your boss would love you to continue working with legacy codebase using PHP instead of migrating parts of it to Python. At the expense of your future career prospects, of course.
I'm talking more about delivering value and less about self-improvement. Both have a time and a place, but your boss is unlikely to look kindly on you saying "I'm interested in learning Python, so I've decided to rewrite our 1mm user web app in Python instead of fixing the bugs you asked me to, because I think I could make more money with that than PHP."
Actually, as a boss I frequently do look kindly on that. I'd much prefer to have that built into assumptions and explicit upfront.
Sometimes I may say "can we do that on our 1K user side project instead?" but I think that if you are managing developmental resources and you are not allowing them learn new things, you are not following a strategy that is likely to work out long term.
You adjust the schedule as required and don't do it for projects with tight deadlines.
The truth is if you don't ensure your developers career development is baked into your schedules then you get a combination of high turnover, unmotivated engineers, and engineers who learn on the clock "in secret" by making decisions that are best for them rather than best for the company.
All of these cause far more problems and are harder to account for than being upfront in the first place.
> and engineers who learn on the clock "in secret" by making decisions that are best for them rather than best for the company
Yes, and possibly not even consciously. Without that constant reminder of the pitfalls and learning curve of new technology, it's easy to convince yourself it's all upsides, or at the least undervalue the downsides.
Easy, you spec out doing it "conventionally" and pad with a reasonable first guess to do something unconventional.
Oh we need that in 2 weeks? And its about one weeks work the old fashioned way? Well try something else fun for a bit less than a week. Sometimes you win, sometimes you lose.
Sometimes you can do both in parallel. In the real world there's always wall clock time delays imposed by whatever. So when you're stuck waiting for whatever, learn as much as you can about XYZ till the main line is unblocked.
I run an in house database with a Django front end.
Started off with the Django Admin application, which is great for getting things up and running quickly. Its definitely been worth learning more and more of Django, as forcing everything into the Admin gets pretty hacky, and basically generates a lot of technical debt.
Spending a bit of time and learning class based views for example (over the function based views) has paid off, as it leads to far more concise code, and basically less code to mange over the long term.
Today for example I know enough about Django and how the Admin application is built from it's components that I am adding features I wouldn't have assumed were possible a couple of years ago. (Stack Overflow hasn't got a decent solution to the question of a redirecting to a confirm page on save - I'll write one up assuming I get it working).
