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 wanted to get back to you, because you are so very right, and I spent the last 10 years or so trying to evangelize the fact that implementing algorithm and logic isn’t the hard part, it is a trivial concern really. Everything that go wrong with development usually involve the flow of data, and figuring out how to get this data from over here to over there without making a big mess. To do that, you absolutely need to write small module with few dependencies. You gotta think about the life-cycle of your objects, and generally follow all the principles of s.o.l.i.d if you’re doing OOP. Personally, I really love using dependency injection when the project allows for it.
It is as you said really, you can have thousands of hours of programming experience but if you never tried to solve those issues you’re really limiting yourself. Some devs think designing software around your data instead of your algorithms is overthinking it, or “overengineering” as I have been told. Well, I would not hire those people for sure.
I have seen clean project made up of small modules, with clear boundaries between data, functions and the lifecycle configurations. It is night and day compared to most code bases. It is really striking just how much of the hidden, and not-so-hidden complexity and goo and hacks and big-ass functions in most code base really just exist because the application life cycle management is often non-existent. In a “proper” code base, you shouldn’t have to wonder how to fetch a dependency, or if an object is initialized and valid, and where to instantiate your module, or even what constructor to invoke to build a new object. This take care of so much useless code it is insane.
To close on this, I like scripting languages a lot as well, and you can do great things with some of them even if lot of developers don’t. JS has Typescript, ReactiveX, dependency injection framework, and etc. It is a great language with a lot of possibility, and you’re not forced into OOP which I think is great (OOP and functional programming are orthogonal solutions imo). But the reality is that the language is really easy to misuse and you can definitely learn bad traits from it. Same as you, I would be wary of a developer with no experience with strongly-typed languages, or at the very least TS. I am very happy to hear this take randomly on the internet, because in my experience, this is not how most developers operate, and imo it is demonstrably wrong to not design applications around your data.
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.
I wanted to get back to you, because you are so very right, and I spent the last 10 years or so trying to evangelize the fact that implementing algorithm and logic isn’t the hard part, it is a trivial concern really. Everything that go wrong with development usually involve the flow of data, and figuring out how to get this data from over here to over there without making a big mess. To do that, you absolutely need to write small module with few dependencies. You gotta think about the life-cycle of your objects, and generally follow all the principles of s.o.l.i.d if you’re doing OOP. Personally, I really love using dependency injection when the project allows for it.
It is as you said really, you can have thousands of hours of programming experience but if you never tried to solve those issues you’re really limiting yourself. Some devs think designing software around your data instead of your algorithms is overthinking it, or “overengineering” as I have been told. Well, I would not hire those people for sure.
I have seen clean project made up of small modules, with clear boundaries between data, functions and the lifecycle configurations. It is night and day compared to most code bases. It is really striking just how much of the hidden, and not-so-hidden complexity and goo and hacks and big-ass functions in most code base really just exist because the application life cycle management is often non-existent. In a “proper” code base, you shouldn’t have to wonder how to fetch a dependency, or if an object is initialized and valid, and where to instantiate your module, or even what constructor to invoke to build a new object. This take care of so much useless code it is insane.
To close on this, I like scripting languages a lot as well, and you can do great things with some of them even if lot of developers don’t. JS has Typescript, ReactiveX, dependency injection framework, and etc. It is a great language with a lot of possibility, and you’re not forced into OOP which I think is great (OOP and functional programming are orthogonal solutions imo). But the reality is that the language is really easy to misuse and you can definitely learn bad traits from it. Same as you, I would be wary of a developer with no experience with strongly-typed languages, or at the very least TS. I am very happy to hear this take randomly on the internet, because in my experience, this is not how most developers operate, and imo it is demonstrably wrong to not design applications around your data.
You put it very well!
I freaking love you and I’ll try to write a worthy reply when I am home.
<3
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.