When I first started, I spent all of my time writing C at my keyboard with few interruptions.
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.
It depends. Being able to do the entire stack yourself saves the communication overhead of working with a group of people.
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.
What does that mean ? If you felt better and personally were prouder of the work done back in C with no autocomplete but the business was deriving more value from your work with autocomplete, how should One answer? Or more importantly, what if the requirements are so much more today that if you adopted the same tools as 20 years ago you’d fall behind?
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.
I wasn’t implying one way or the other and I don’t think that the parent post was either.
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.
Once a code base reaches a million lines of code it gets difficult to keep it all in your head, and even if the software has a nice architecture with module patterns or what not, just the sheer amount of different methods and functions will slow you down. Sure autocomplete will help, but the best productivity solution afaik is to keep the code base small :P
> A kernel developer usually contributes both code and documentation to the Linux kernel. As kernel developers become experts in their particular subsystem, they contribute to patch review on the subsystem mailing list. Eventually, they may become the maintainer of a particular driver.
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.