I think generally a company is either in the business of making general purpose solutions (reusable code) or client solutions (non-reusable code). It's not really possible, probably not even recommended, to try and mix the two models within a company (or at least within a division).
But even though you make client solutions you surely run into small scale situations where code reuse seems appropriate.
You don't want to make the same business validation rules in multiple places. Or maybe your client has multiple applications and you want a consistent user interface across the apps. That all leads to wanting to reuse code.
I feel the article has a good point though. Code which is reused a lot quickly becomes difficult to manage. Especially if you are missing automated testing to reassure you that nothing goes wrong when you refactor or change common code.
I don't have a problem with reusing code so much as sharing code, that's when the problem starts. Each client should just get a fork of the code and then you start modifications. If a client wishes to upgrade their project you can look at merging in changes then. If they just need minor changes then you stick with the old version. That is, treat it like software with a distinct release for each client, and don't attempt to actually share one version of the code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think generally a company is either in the business of making general purpose solutions (reusable code) or client solutions (non-reusable code). It's not really possible, probably not even recommended, to try and mix the two models within a company (or at least within a division).
But even though you make client solutions you surely run into small scale situations where code reuse seems appropriate.
You don't want to make the same business validation rules in multiple places. Or maybe your client has multiple applications and you want a consistent user interface across the apps. That all leads to wanting to reuse code.
I feel the article has a good point though. Code which is reused a lot quickly becomes difficult to manage. Especially if you are missing automated testing to reassure you that nothing goes wrong when you refactor or change common code.
Reuse in a team is good, and cheap. Reuse across teams is hard. Reuse across the enterprise needs to be deliberated, and managed, and is costly.
I don't have a problem with reusing code so much as sharing code, that's when the problem starts. Each client should just get a fork of the code and then you start modifications. If a client wishes to upgrade their project you can look at merging in changes then. If they just need minor changes then you stick with the old version. That is, treat it like software with a distinct release for each client, and don't attempt to actually share one version of the code.