I spend several hours a week learning more about programming languages, stacks, pipelines, patterns, anti-patterns, concepts, frameworks, and practices relating to building software. Knowing syntactical differences between a dozen object oriented languages has never been on my agenda. Language adoption happened rather organically as job opportunities presented themselves over the last fourteen years. My primary stints so far being several years each with PHP, ColdFusion, Java, and my longest and most recent C# on the backend. All of these are roughly interchangeable and suitable for building server-side logic. As the years go by I care less about the language. Especially since C# has proven to be a solid choice over the past six years. And it should maintain it’s place as more features are added.
It’s the Indian not the arrow
I have been enamored with principles of functional languages and how they can help me produce better software. I am all over F#, too. And Domain Driven Design, CQRS, and Event Sourcing are blowing my mind as well since I grew up playing with the big ball of mud. Although it is a shame that I am over a decade late to the party, I get to dance the rest of my career.
Applying the learned skills
Growth begins after the first release.
Pushing out the first release is fun, yes. But only after a product has usage and the feedback loop is closed does the real potential for growth present itself. If you are adhering to agile principles you probably did not take months to push out the MVP release. And this may mean the product is rather vanilla or feature light. But with each successive release the product grows either in features or complexity. But the developers are able to utilize a deeper technical understanding of the product along with the old and new skills to produce a maintainable quality version of the product that satisfies the next round of refined user stories.
The more tenured the developer and the developer with a product the better the quality of the product.
It is good that a developer learns frameworks to save time, promote consistency, and patterns for writing more bug free code. If that developer works on small and isolated features for lots of software products, think coder in a software shop, I argue that the level of impact made on each of those projects would not be as significant as that which could be made over a significant portion of the lifetime of few software products.