3 ms·

How much of the new languages are supported by a new fresh wave of engineers that want to learn things? To become a good engineer I had to go through implement

How much of the new languages are supported by a new fresh wave of engineers that want to learn things? To become a good engineer I had to go through implementing my own container types, play with my own little databases and network libraries, implement a build system, ... I published a few of those experiments in Ruby, the new/hip language at the time. Picking a fresh language seems the obvious playground to do this, it's where you can leave your mark. My impression was that nodejs developers' age distribution was quite young as well when it started. My point is that it's necessary to introduce new languages once it a while to get good engineers :)

bunderbunder 8y ago
Tangential anecdote: At one company I worked for, the guy in charge of ops had put a whole lot of work into standardizing the production environment and tooling, and getting it all tuned just so. A couple years later, he lamented that new hires were achieving deep competence more slowly, and weren't reaching the same level of competence that previous team members used to. It wasn't a big deal most the time, but they made a lot of mistakes when rolling out new components, and tended to get caught flat-footed whenever something went sideways. He suspected that the problem was that, in its current state, the new system worked so smoothly that they could get away with understanding things at a very superficial level, and that hindered their learning.
BeetleB 8y ago
That was my first thought when I read the post: He's discounting the fact that by doing this, many programmers are gaining in expertise. It's not a given that those programmers would grow their skill set as much otherwise. Advancing the state of the art in a well established language requires a lot more skills than implementing simple libraries for a new language.
- mike_hearn 8y ago
  Yeah, but they could write potentially useful apps or features, instead of badly re-writing libraries that already exist.

bunderbunder 8y ago

Tangential anecdote: At one company I worked for, the guy in charge of ops had put a whole lot of work into standardizing the production environment and tooling, and getting it all tuned just so. A couple years later, he lamented that new hires were achieving deep competence more slowly, and weren't reaching the same level of competence that previous team members used to. It wasn't a big deal most the time, but they made a lot of mistakes when rolling out new components, and tended to get caught flat-footed whenever something went sideways. He suspected that the problem was that, in its current state, the new system worked so smoothly that they could get away with understanding things at a very superficial level, and that hindered their learning.

BeetleB 8y ago

That was my first thought when I read the post: He's discounting the fact that by doing this, many programmers are gaining in expertise. It's not a given that those programmers would grow their skill set as much otherwise. Advancing the state of the art in a well established language requires a lot more skills than implementing simple libraries for a new language.

mike_hearn 8y ago
Yeah, but they could write potentially useful apps or features, instead of badly re-writing libraries that already exist.