I’d change this slightly - the problem isn’t exclusively working in scripting languages, but dynamically typed ones. There are people who write great code in Python (with typing) and in Typescript, and they usually can work well in other languages too. But people who don’t type their programs are in my experience simply bad developers, the way you describe.
I feel like there is a fundamental difference between developers with a data-centric perspective, and a function-centric perspective.
The function-centric one is about adding functionality, and it’s what developers start out with. You have functions that do things, and if requirements change or the thing should be re-used - no problem, I can quickly add a new toggle parameter here or bolt it on over there. I’ll be done in 5 minutes, no problem!
Then, over time, you learn that functionality isn’t that interesting or difficult. Instead, the hard parts are the ones concerning the flow of data through your application. What do I know about the shape of my data in this part of my application? What can I be sure of regarding invariants over there? This forces you to build modular software without interdependencies, because - in the end - you just build a library that has small adapters to the outside world.
I like scripting languages a lot, but it’s way too easy to become “good” at that style of programming, and the better you get at it, the harder it will be to actually move forward to a data-centric perspective. It’s a local maximum that can trap people, sometimes for their whole career. That’s why I try to look at typing experience when evaluating candidates for positions.
I’d change this slightly - the problem isn’t exclusively working in scripting languages, but dynamically typed ones. There are people who write great code in Python (with typing) and in Typescript, and they usually can work well in other languages too. But people who don’t type their programs are in my experience simply bad developers, the way you describe.
True that, this was pretty much the intended meaning of my reply but you worded it better.
Ah, good!
I feel like there is a fundamental difference between developers with a data-centric perspective, and a function-centric perspective.
The function-centric one is about adding functionality, and it’s what developers start out with. You have functions that do things, and if requirements change or the thing should be re-used - no problem, I can quickly add a new toggle parameter here or bolt it on over there. I’ll be done in 5 minutes, no problem!
Then, over time, you learn that functionality isn’t that interesting or difficult. Instead, the hard parts are the ones concerning the flow of data through your application. What do I know about the shape of my data in this part of my application? What can I be sure of regarding invariants over there? This forces you to build modular software without interdependencies, because - in the end - you just build a library that has small adapters to the outside world.
I like scripting languages a lot, but it’s way too easy to become “good” at that style of programming, and the better you get at it, the harder it will be to actually move forward to a data-centric perspective. It’s a local maximum that can trap people, sometimes for their whole career. That’s why I try to look at typing experience when evaluating candidates for positions.
That’s true.
It’s also true in other fields. For example, take far-eastern fighting skills:
Young students will try to hit someone, to beat someone up, to hit a target, to become “stronger”.
Experienced teachers, however, don’t really care about hitting a target. It’s all about the posture. How you stand. How you carry out your movements.