But on the other hand, for the good of the company, it’s often good to sub optimize the individual for the good of the team. You usually don’t want only one person knowing the entire feature and while you will lose out on individual productivity, you can get features out sooner if you have more people working on it.
On a personal level, I love having not to wait on other departments/props to get my work done especially in a dev environment.
I admire those who stick with their old tools and forgo modern ones so they can stay sharp. They tend to miss the forest for the trees though.
The point I was making that when I was writing C day in and day out and mostly just working with a combination of my own code and my companies vote libraries, it was easy to use just a text editor and the command line to build.
But things have gotten more complicated since then. No one could be expected to know the hundreds of functions that make up the entire AWS SDK or all of the options that you need to specify for a typical CloudFormation stack in yml. Of course now it’s even better with the Cloud Developer Kit that lets you generate yml programmatically using a static language - with autocomplete.
This sounds good to me. I'm not qualified to judge the quality of the linux kernel, but judging by the adoption, many features, and hardware support, they must do something right.
Two decades later, at any given time, I’ll be writing C#, Python, Javascript, yml for CloudFormation, a litany of third party external dependencies, internal libraries written by developers on multiple teams, etc.
Not to mention “polyglot persistence” dealing with Mysql, DynamoDB and ElasticSearch. All that and Zi purposefully avoid the front framework of the week.
The scope of what I am expected to know changes.